Browse Tag

Organisation

Book vector designed by Freepik

Rezension: Personal Kanban

Personal Kanban ist ja so im Allgemeinen ein interessantes Thema und aktuell in aller Munde. Da ich privat, für meine diversen Projekte und viele private Tätigkeiten stets ein Board pflege, fand ich das Buch mit dem Titel „Personal Kanban – Visualisierung und Planung von Aufgaben, Projekten und Terminen mit dem Kanban-Board“ interessant. Bisher hatte ich meine Kenntnisse aus meiner täglichen Arbeit in meine Personal Kanban Boards einfliessen lassen und war gespannt, was ich noch zusätzlich durch das Buch in Erfahrung bringen konnte. 

„Alle, die ihre Aufgaben, Projekte und Termine im Berufsleben, Privatleben und sozialen Leben stressfreier und effektiver organisieren möchten.“

Mit dieser Beschreibung, die auf dem Buchrücken zu finden ist, fühlt sich jeder sofort angesprochen und möchte mehr erfahren. Weiterlesen

sprintzero

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

People vector designed by Freepik

Product Owner im Potrait – Interview Heike Funk

Wie in der vergangenen Woche angekündigt, starten wir in dieser Woche mit der Serie „Product Owner im Potrait“. Heike Funk wird heute über ihre Erfahrungen in der Rolle als Product Ownerin berichten. Lernen sie ihre persönlichen Erfolgsfaktoren innerhalb eines Scrum Teams, der Arbeit mit Kunden und Abstimmung mit Projektbeteiligten kennen. Erfahren sie, welche persönlichen und allgemeinen Herausforderungen dieser zentralen Scrum Rolle anhaften und welche Fehler auf keinen Fall gemacht werden sollten. 

Steckbrief

  • Name: Heike Funk
  • Alter: 31
  • Angestellt als: Director eRecruiting Products
  • Product Owner Rolle seit: April 2010
  • Berufserfahrung gesamt: 10 Jahre
  • Branche: Internet
  • Produkt Thema: Job-Portal

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

Als Product Owner trägt man volle Verantwortung für sein Produkt. Alles, was man tut, ist darauf ausgerichtet, das Produkt erfolgreich zu machen. Hierfür benötigt man Input von vielen Stakeholdern – internen und externen. Am Wichtigsten sind natürlich die Kunden bzw. Nutzer des Produktes und diejenigen, die wir zu Nutzern machen wollen. Es gilt herauszufinden, was sie sich wünschen und das dann zusammen mit den Kenntnissen über den entsprechenden Markt in die Entwicklung des Produktes einfließen zu lassen. Aber auch diverse interne Stakeholder haben Input und Ideen für ein Produkt. Diese sollte man als Product Owner aufnehmen und neben eigenen Ideen bewerten, verwerfen oder berücksichtigen. Am Ende muss man selber entscheiden, was als nächstes umgesetzt wird und das dann auch vertreten. Für mich ist dies oftmals die größte Herausforderung. Man kann selten allen Leuten gerecht werden und es wird oftmals verlangt, dass man Entscheidungen ausgiebig rechtfertigt, noch bevor der Erfolg abgewartet wird. Weiterlesen

Business vector designed by Freepik

Gastbeitrag: Faule Projektmanager

Gastbeitrag: Sven Röpstorff www.agiletransparency.com

Im letzten Jahr hatte ich das große Vergnügen, an einem Vortrag von Peter Taylor teilzunehmen. Peter sagt von sich selbst, dass er ein Lazy Projectmanager sei. Diese provokante Bezeichnung macht natürlich neugierig. Nun haben wir vermutlich alle in der Schule gelernt, dass das englische Wort „lazy“ auf deutsch „faul“ bedeutet. bab.la Wörterbuch übersetzt „lazy“ mit „faul“, „langsam“, „träge“ und „lustig“. Keine dieser Übersetzungen wird aber einem Lazy Projectmanager gerecht.

Peter bringt das Beispiel des preußischen Generalfeldmarschalls Helmuth Karl Bernhard Graf von Moltke (*1800 – †1891), der seine Offiziere in vier Kategorien eingeteilt hat:

  • Kategorie A: dumm und faul
  • Kategorie B: intelligent und tatkräftig
  • Kategorie C: dumm und tatkräftig
  • Kategorie D: intelligent und faul

Weiterlesen

Background vector designed by Freepik

Einsatz von Tiger Teams in Pilotprojekten

Eine interessante Herangehensweise, um Scrum im Unternehmen zu etablieren, habe ich auf dem Scrum Day 2009 von Dr. Andrea Tomasini mitgenommen – der Einsatz von Tiger Teams.

In dem dort gezeigten Beispiel, wurde Scrum anhand eines für das Unternehmen strategisch wichtigen Pilotprojekts erfolgreich verbreitet. Wie man das richtige Pilotprojekt identifiziert, beschreibt Mike Cohn in einem kürzlich verfassten Artikel. Hat man das Pilotprojekt im Unternehmen ausfindig gemacht, geht es an die richtige Besetzung des Teams. Hierzu wählt man die besten Leute aus dem Unternehmen aus bzw. diejenigen, die über Erfahrungen mit agiler Softwareentwicklung verfügen. Die Sprunglatte für das erste Projekt setzt man so hoch an, dass man noch drüber springen kann oder mit anderen Worten, dass das Ziel gut erreichbar ist und genügend Business Value geliefert werden kann. Man erzielt somit den Effekt, dass einerseits das Team den Scrum Prozess verinnerlicht und anderseits, ein erfolgreiches Projekt hochgehalten werden kann. Dies dient anschließend dazu, Argumente für den Einsatz von Scrum zu finden. Das vorrangige Ziel des Tiger Teams wird nun deutlich – es soll Scrum an andere weitergeben.

Auf dem Scrum Day (hier mein Rückblick) brachte Tomasini dazu folgendes Beispiel an: Das Pilotprojekt wurde erfolgreich durchgeführt und gelauncht. Nun sollten auch alle anderen aus der Entwicklungsabteilung in fünf neue Teams aufgeteilt werden. Dazu wurden alle notwendigen Personen in einen Raum zusammengebracht, um sich unter der Bedingung – jedes Team soll zwei Personen aus dem Tiger Team aufnehmen – zusammenzustellen. Das Involvement und die Evolution der Teams wurden dabei quasi von Grund auf mitgeliefert.

Hat jemand ähnliche Erfahrungen gemacht bzw. dasselbe Vorgehen gewählt?

Graphic Resource: Background vector designed by Freepik