Browse Tag

Zusammenarbeit

Impro(ve) Agile Game Session auf der Social Media Week 2017

„Dir wächst da was aus den Ohren – ist das Brokkoli?“

Zum zweiten Mal nahmen Laura und ich beim StartUpDay im Rahmen der Social Media Week teil. In der Session mit dem Namen „Impro(ve) Agile“ sollten die Teilnehmer nicht nur Inhalte konsumieren, sondern vor allem auch partizipieren. Damit war bei vielen der Anwesenden die Überraschung perfekt, da sich das Angebot von den übrigen Formaten absetzte. Ziel war es, einen Raum zu öffnen, in dem die Teilnehmer ganz selbstverständlich aktiv mitmachen, hier und da über sich hinausgehen und vor allem Spaß haben.

Die interaktive Session brachte den Teilnehmern agile Werte auf spielerische Weise mit Methoden aus dem Improvisationstheater näher. Die Idee war für uns sehr naheliegend, da es beim Improvisationstheater darum geht, aufeinander zu achten, zusammenarbeiten, zu kommunizieren und aneinander zu vertrauen. Laura, die eine sehr lange Theater- und Improvisationstheater-Vergangenheit hat und in ihrer Freizeit aktiv „Impro spielt“,  warf einmal in einem Gespräch diese enge Verbindung auf. Eine Idee war geboren und musste ausprobiert werden.

Improvisieren auf der Bühne – wie im Arbeitsalltag

Viele wichtige Regeln für das Improvisieren auf der Bühne gelten auch für den Arbeitsalltag in Teams. Ebenso spielen agile (Scrum) Werte wie Fokus, Respekt, Offenheit, Commitment oder Mut eine wichtige Rolle im Improvisationstheater. Die Transition in Unternehmen, der Kulturwandel hin zu agilen Teams verlangt den beteiligten Menschen oftmals einiges ab. Mit gutem Gewissen könnte ich auf Teams zugehen und ihnen die folgende Regeln aus dem Improvisationstheater vorstellen: Weiterlesen

(M)ein bunter Beitrag

Zu meiner Rolle gehört auch, dass ich mich nicht unbedingt immer beliebt mache. Ich denke hier vor allem auch an die Finanzabteilungen der Unternehmen in denen ich tätig bin. Dort steigen die Ausgaben für „Büromaterial“ nämlich erheblich an, da es sich im Laufe der Zeit bisher immer etabliert, dass Post-its zum Hauptwerkzeug der Wahl werden (btw. das Investment hat sich bisher immer ausgezahlt). Sei es bspw. zur Visualisierung von Aufgaben im Team, zum Festhalten von Ideen in Workshops oder zur Raumgestaltung. 😉

In einem bunten Beitrag habe ich kurz dokumentiert, worauf man sich mit mir einlässt. 😉

Grapic Resource: Background vector designed by Freepik

100% Auslastung – alles Einstellungssache

Boris Gloger schrieb vor einiger Zeit, dass Denken in Auslastung blödsinnig ist. Angeregt durch den Beitrag und das Thema, fielen mir Situationen ein, bei denen Manager auf mich als Scrum Master oder meinen Product Owner zukamen und behaupteten, dass die Teams, mit denen ich arbeitete, nicht ausgelastet seien. Nach einem kurzen Gespräch mit den Managern und betroffenen Teammitgliedern, konnte ich mir dann schnell ein Bild von der eigentlichen Situation machen und die Kommunikation in die richtige Richtung lenken. Wie kam es zu der Annahme und was tue ich in diesen Situationen?

Das Missverständnis

Treffen sich ein Manager und Entwickler auf dem Flur. Sagt der Manager „Na, wie läufts bei euch im Team, kommt ihr voran?“ Darauf sagt der Entwickler „Diesen Sprint habe ich nicht wirklich etwas zu tun, da das Sprint Backlog nur Backlog Items für die Frontend-Entwickler enthält.“ Denkt sich der Manager „Hmmm…, da sitzt jemand rum und hat nichts zu tun!“.

Sie merken, dieser angedeutete Witz hat keine Pointe, weil diese Situation in vielen Unternehmen zum Alltag gehört. Was so nebenbei beim Small-Talk ausgetauscht wird, wirkt sich häufig in falschen Annahmen aus. Leider ist es bei vielen Managern immer noch so, dass sie annehmen, eine 100% Auslastung sei erstrebenswert. Wenn also jemand sagt, dass er „nichts zu tun hat“, dann bedeutet dies für den Manager, dass nicht effizient gearbeitet wird oder der Drang zum regulierenden Eingreifen steigt. Als Scrum Master ist es in diesen Situationen wichtig, in Richtung Management und Scrum Team zu kommunizieren. Weiterlesen

Product Owner im Portrait: Interview Björn Waide

Im heutigen Interview steht Björn Waide (@waide) meinen Fragen Rede und Antwort. Björn bekleidet die Rolle als Product Owner seit geraumer Zeit und blickt auf einen reichen Erfahrungsschatz in der Arbeit mit diversen Scrum Teams zurück. Nach dem Studium der Informatik startet Björn als Software-Entwickler in das Berufsleben und ist mittlerweile sechs Jahre als Produktmanager tätig. Durch die Arbeit in einem agilen Arbeitsumfeld verantwortete er in den letzten drei Jahren verschiedene Produkt-Initiativen in der Rolle des Product Owners. Erfahren sie im Interview mehr über seine Erfahrungen, Herausforderungen und Tipps.

Steckbrief

  • Name: Björn Waide
  • Alter: 32
  • Angestellt als: Director Product Management
  • Product Owner Rolle seit: 2009
  • Berufserfahrung gesamt: 6 Jahre
  • Branche: Internet, Dienstleistung
  • Produkt Thema: Social Network

Was ist deines Erachtens das Schwierigste bei der Erfüllung der Product Owner Rolle?

Die Product Owner Rolle stellt hohe Anforderungen aus allen möglichen Teilgebieten an den, der sie ausfüllen soll. Man muss sich in Details auskennen und doch immer das große Ganze sehen. Muss mit Entwicklern über technische Machbarkeit diskutieren oder mit dem Marketing über Produkteinführungsstrategien. Es gibt wohl kaum jemanden, der alle Anforderungen aus allen Teilgebieten gleich gut abdeckt. Für jeden wird also die Schwierigkeit an einer anderen Stelle liegen. Es ist wichtig, sich selbst zu reflektieren und an den Punkten, an denen Wissen oder Erfahrung fehlt, Hilfe von Kollegen oder Fachspezialisten einzuholen. Weiterlesen

Gastbeitrag: Sprint Zero – Die Null muss stehen

Gastbeitrag: Sven Röpstorff www.agiletransparency.com

Wenn man ein neues Projekt bei einem Kunden beginnt, muss man sich die Projektumgebung oft selbst organisieren oder doch zumindest sicherstellen, dass sie den eigenen Ansprüchen genügt. Gerade bei Scrum-Projekten möchte man gleich mit dem ersten Sprint Funktionalität implementieren und sich nicht erst noch mit organisatorischen Problemen herumschlagen, die man durchaus vorher hätte erledigen können. Trotzdem bin ich immer wieder überrascht, wie schlecht vorbereitet manche Teams in ihren ersten Sprint geschickt werden. Dabei ist es doch eigentlich ganz einfach –  man führt vor Sprint 1 einen sogenannten Sprint Zero durch. In diesem vorgelagerten Sprint wird der die Umgebung und der erste Sprint so vorbereitet, dass man sofort mit der Implementierung von Funktionalität beginnen kann. So vermeidet man die üblichen Probleme, z.B. dass man keinen Zugang zum Entwicklungsserver hat, dass ein Entwickler gern einen zusätzlichen Monitor hätte, dass die Stühle im Projektraum Rückenschmerzen verursachen usw.

Der Sprint Zero ist natürlich projekt- und unternehmensspezifisch, aber das folgende Praxisbeispiel gibt vielleicht einen guten Einblick, was man machen kann.

Weiterlesen