Alexander Maisch
Donnerstag, der 3. Dezember 2009

Vom „Erfinder“ des Open Space

So als kleine Einstimmung auf unsere Open Space Veranstaltung morgen erzählt hier  Der „Erfinder“ des Open Space Harrison Owen eine kleine (launige) Geschichte zur Gründungslegende. (Die habe ich auch schon in anderen Varianten gehört, da ist er wohl kreativ )

Viel Spaß und bis morgen..

Am 20. Juni 2009 hatten Bernhard Findeiss und ich das Vergnügen einen Vortrag zum Thema Streitkultur und Retrospektive in Scrum auf der InterPM 2009 zu halten.

Die Konferenz (und damit unser Vortrag) bot gleich in mehreren Aspekten Neuland für uns:

  • Das Publikum der InterPM ist im positiven Sinne recht bunt. Es finden sich Projektmanagement-affine Besucher aus den verschiedensten Fachrichtungen. Mit Sozialwissenschaftlern, Betriebswirtschaftlern, Medizinern, Ingenieuren, Naturwissenschaftlern, Psychologen, Wirtschaftsinformatikern und Informatikern war eine recht vielschichtige Auswahl von Fachrichtungen da.
    Das heißt, wir mussten uns aus dem gewohnten (geliebten?) technischen Kreisen raus bewegen.
  • Um mal die allzu ausgetretenen Pfade der Powerpoint-Präsentationen zu verlassen, haben wir dafür mal eine neue Form ausprobiert.
  • Wir mussten nach Hessen 😉

Um viele Eindrücke kurz zu fassen – ich war recht begeistert, der teilweise durchaus kritische Diskurs der Themen war sehr angeregt, unser Vortrag lief recht gut, die Präsentation hat (nach anfänglichen Schwierigkeiten mit dem Beamer) gut funktioniert und Hessen ist auch OK.

Wer Interesse hat, kann sich gerne unsere Präsentation bei Prezi ansehen. Zu der Konferenz gibt es auch einen Tagungsband mit recht lesbaren Beiträgen der Teilnehmer. Unser Beitrag zum Tagungsband steht natürlich auch im  Downloadbereich zur Verfügung. (Tagungsbeitrag InterPM 2009: Retrospektiven und Streitkultur (2700))

Alexander Maisch
Dienstag, der 28. Oktober 2008

Der Über-Product-Owner

Das ist doch schön zu sehen, wenn meine eigenen Ideen, die Rolle des ProductOwners zu visualisieren auch von „großen Geistern“ geteilt werden: Jeff Sutherland schreibt dazu auf seinem Blog „World’s Best Product Owner: Evil Genius Steve Job„.

Kurz, aber mal wieder ein Lebenszeichen …

Alexander Maisch
Donnerstag, der 3. Juli 2008

Die Scrum-Sprechstunde: Rollen in Scrum

In Scrum gibt es genau drei verschiedene Rollen, die ein Projektbeteiligter einnehmen kann: ProductOwner (PO), Team und ScrumMaster (SM).

Zusätzlich könnte man noch von einer vierten „virtuellen“ Rolle sprechen, nämlich die der „Chicken“.

ProductOwner (PO)

  • Der PO entwickelt und kommuniziert die Vision, was entwickelt werden muss, um geschäftlichen Erfolg zu haben.
  • Er ist verantwortlich für den geschäftlichen Erfolg der Entwicklung (ROI)
  • Er formalisiert die Vision in einer Liste von gewünschten Features (ProductBacklog)
  • Er kommuniziert direkt mit dem Team und steht diesem für Nachfragen und Diskussionen zur Verfügung
a product owner

Team

  • Das Team stellt in regelmäßigen kurzen Abständen (Sprint) dem Auftraggeber die entwickelten und getesteten Leistungen zur Verfügung.
  • Das Team ist interdisziplinär besetzt.
  • Das Team arbeitet selbstorganisiert und -verwaltet
  • Jeder im Team trägt mit seinem gesamten Wissen zum Erfolg bei (unabhängig von hierarchischer Position und formeller Qualifikation).
a scrum

ScrumMaster

  • Der SM ist Coach für das Team und den PO in allen Scrum-Belangen
  • Er moderiert Meetings
  • Er beseitigt Hindernisse in der Organisation (oder ganz allgemein dem Umfeld des Teams)
  • Er sorgt für die Unterstützung und Anerkennung der agilen Prinzipien (Scrum) durch alle Stakeholder
  • Er „beschützt“ das Team vor Störungen von außen.

Chicken

Als Chicken werden in Scrum alle die bezeichnet, die zwar Interesse am Projektfortschritt haben, die aber nicht aktiv am Projektfortschritt beteiligt sind, sich also nicht zu den jeweiligen Sprint-Zielen „comitted“ haben.

Bei den meisten Meetings können Chicken zwar anwesend sein, sprechen dürfen sie aber eigentlich nur im Sprint-Review, also bei der Präsentation am Ende des Sprints.

Mehr zur Herkunft des Titels „Chicken“ könnt Ihr im Blog „Implementing Scrum“ finden…

dann mal bis zum nächsten Mal …

AXM

Alexander Maisch
Freitag, der 13. Juni 2008

Die Scrum-Sprechstunde: der Nokia-Test

Bei InterFace haben wir ein Forum für den Austausch aller an Scrum interessierten Kollegen:

Die Scrum-Sprechstunde.

Hier diskutieren wir über verschiedene Themen im Umfeld von Scrum – wie beispielsweise die Skalierung von Scrum, Scrum im Management oder Scrum im Alltag der Berater – um nur einige zu nennen. Ganz oft geht es aber auch um die grundlegenden Fragen zum Verständnis von Scrum.

Ich werde hier in loser Folge ausgewählte Themen aus diesen Scrum-Sprechstunden zusammenfassen und zur weiteren Diskussion stellen.

Heute mache ich den Anfang mit dem Nokia-Test.

Ich habe schon öfters Dikussionen erlebt, in denen sinngemäß die Frage „Wir machen in unserem Projekt aber XYZ – Ist das denn noch Scrum?“ oder Aussagen wie „Ohne XYZ kann das gar kein echtes Scrum sein.“ gefallen sind.

Im Internet kann man dazu so einige Checklisten finden. Ich möchte hier kurz eine Liste von Fragen vorstellen, die Nokia verwendet, um seine Projekte auf die Anwesenheit von iterativen Verfahren und Scrum zu testen (Gefunden habe ich das ganze hier).

Damit Ihr da nicht selbst nachlesen müsst schreibe ich sie auch hier auf:

Der Test besteht aus zwei Teilen. Der erste Teil testet die „Iterativität“ des Vorgehens:

  • Iterationen haben eine feste Länge von nicht mehr als vier Wochen.
  • Die am Ende jeder Iteration ausgelieferte Software ist getestet und für den Kunden funktionsfähig.
  • Die Iteration startet bevor die Spezifikation komplett ist.

Der zweite Teil testet, ob das Vorgehen Scrum entspricht (nach Nokia-Maßstäben):

  • Du kennst den ProductOwner
  • Es gibt ein nach Geschäftswert priorisiertes Product-Backlog
  • Die Einträge des Product Backlog sind vom Team beschätzt
  • Das Team erstellt Burndown Charts und kennt seine Entwicklungsgeschwindigkeit (Velocity)
  • Es gibt keine Projektmanager (oder sonstjemanden), der die Arbeit des Teams stört.

Ein solcher Test eignet sich sicherlich gut, um CowboyAgile von Scrum zu unterscheiden. Allerdings wird es gerade in der Einführungsphase von Scrum häufig Abweichungen davon geben. Trotzdem ist es immer wieder hilfreich mit Hilfe solcher „externen“ Benchmarks die eigenen Vorgehensweisen (und vermeintlich nicht zu verändernden Rahmenbedingungen) zu hinterfragen.

Soweit zum ersten (zugegebenermaßen kleinen) Thema aus der Scrum-Sprechstunde. Das nächste Mal werde ich die verschiedenen Rollen in Scrum beleuchten.

AXM