Tuesday, November 8, 2011

Die Rolle des Product Owner im Agilen Multiprojekt Umgebungen

Agiles Projektmanagement unterscheidet sich vielfältig von der agilen Softwarentwicklung. Unsere Erfahrung in den letzten 18 Monaten hat gezeigt, das vor allem an die Rolle des Product Owner (PO) vollständig andere Anforderungen gestellt werden müssen...
Da die Anforderungen an ein agiles Projektteam oft von Fachabteilungen gestellt und definiert werden die in einem nicht agilen Umfeld zu Hause sind, ist die Rolle des Product Owner durchaus mit der eines Proxies zu vergleichen.
Zum einen wird durch den PO die Terminologie im inneren des agilen Teams in einen "natürliche„ Business Sprache übersetzt, zum anderen muss der Product Owner einen ausreichenden fachlichen Background mitbringen (abbilden können) um die Anforderunegn der Fachseiten in valide Userstories übersetzten zu können. Zu guter Letzt muss der PO im Sprint die Rolle der Fachabteilung abbilden und dem agilen Team als kompetenter Ansprechpartner in fachlichen Fragen zur Verfügung zu stehen.
In vielen Unternehmen sind derartige Rollen rar und in den meisten Fällen handelt es sich um versierte, seniore Busiess Analysten. Die Anforderungen an den PO sind sowohl breit, im Business Verständnis, als auch tief, in fachspezifischen Details. Schwierig ist speziell in hierarchischen Unternehmen die "Position" des PO bezüglich seines Ansehens und "credibility".
In vielen Unternehmen sind derartige Rollen rar und in den meisten Fällen handelt es sich um versierte, seniore Busiess Analysten. Die Anforderungen an den PO sind sowohl breit, im Business Verständnis, als auch tief, in fachspezifischen Details. Schwierig ist speziell in hierarchischen Unternehmen die "Position" des PO bezüglich seines Ansehens und "credibility".
Unsere Erfahrung hat ergeben das speziell in hierarchisch / politischen Projekten die Rolle des PO sinnvollerweise von dem Ranghöchsten Mitarbeiter mit der entsprechenden fachlichen Qualifikation ausgefüllt wird.
Im optimalen Fall spiegelt der PO einen (mehrere) fachseitigen Produkt Manager der die fachliche Verantwortung für das Produkt / Thema hat.


Durch die Proxie Funktion des PO wird die Notwendigkeit des agilen Verständnis der fachseitiegen Produkt Manager deutlich reduziert, was den Einsatz von agilen Projektmanagement in vielen Unternehmen erst denkbar und möglich macht.


Gruss,
Matthias Assmann

Kommentare???

Wednesday, September 14, 2011

Buchreview: 31 Days to Finding Your Blogging Mojo

Hello Bloggers, look at your blog. Now look at mine. Look at your blog, and BACK to mine.
Does your blog roll as good as mine, probably not, but do you want it to!?
(errrrmmm....)

Wäre ein super Intro wenn ich ein gut laufendes Blog hätte, hab' ich aber nicht.

Als ich las das Bryan Allain eine vorab Version seines Buches "31 Days to finding your blogging mojo" gratis an Blogger verteilt war ich direkt interessiert. (Der Deal ist das man ein Review blogt.....)
Bloggen wollte ich schon länger regelmäßig, aber habe es nie geschaft eine Gewohnheit daraus zu machen (mal abgesehen von mein Twitter Profil).

Das Buch ist lustig und leichtherzig geschrieben. Für jeden der 31 Tage gibt es ein bis anderthalb Seiten zu lesen, und eine kleine Aufgabe zu bewältigen, zum Beispiel:

  • suche in dein Blogarchiv vom letzten Jahr 10 Posts heraus, und überlege wie du die Thematik Heute anders an gehen würdest
  • Überlege aus welcher Perspektive du blogst, und ob dies für alle deine Posts die gleiche ist (oder sein soll)
  • Versinnbildiche dein Blogpublikum auf einer Person (dein Tyler Stanton), das ist deine Zielgruppe
Zwischen den Kapiteln gibt es immer skurille Gedanken von Bryan zu Gott und die Welt. Kann man mögen, muss mann aber nicht.

Ist das Buch revolutionär? Nein, bestimmt nicht, wer sich viel im Internet rum treibt, und bekannte bestimmte Personen auf Twitter folgt (zB: Jeff Goins oder Michael Hyatt) wird Einiges über Bloggen und Schreiben im Allgemeinen lesen. Das Wissen was im diesen Buch vermittelt wird besteht eher aus Common Knowledge und Best Practises.
Aber, für $ 5,74 (Kindle edition) bekommt man hier auf 100 Seiten das Wissen kompakt, witzig und in gut verdauliche Häppchen präsentiert. Wer sich nicht sicher ist, wie er mit sein Blog vorwärts kommt, oder wo er mit sein Blog hin will, kann ich das Buch nur wärmstens empfehlen.

Wer mehr erfahren möchte, es gibt auch eine Website: http://31daystomojo.com

Tuesday, August 30, 2011

GTD Treffen im Unperfekthaus in Essen

Wer sich mit GTD beschäftigt, oder mit den Gedanken spielt dies zu tun, kann sich hier mit anderen zum Erfahrungsaustausch treffen.

Treffpunkt ist das UPH in Essen (link) im Eingangsbereich.
Am Montag den 5. September 2011 von 20:00 bis 22:00 Uhr.
Wer ein Facebook Account hat, kann den Termin hier bestätigen.

Ich freue mich drauf euch zu treffen!

Gruss

Huibert Gill

Wednesday, June 29, 2011

SCRUM als Projektmanagement in Multiprojektumgebungen

Das Problem:
Im Rahmen eines 2 Wöchigen Sprint werden mehrere Teilprojekte vom Team bearbeitet. Der Sprint Backlog ist nicht immer vollständig abgearbeitet, da sich selbst wahrend des Sprints die Randbedingungen für Projekte ändern.
Lösung:
es wird zusätzlich zum Sprint ein übergeordnetes Sprintziel vereinbart. Dieses muss nicht alle Aufgaben des Sprint enthalten, sondern fokussiert auf ein Hauptziel. Hierdurch wird das committment und die Zufriedenheit im Team erhöht, da Politische Impact wahrend des Sprint besser kontrolliert werden kann.

Meinungen?

Monday, May 23, 2011

The 15-Minute-Meeting

Kennen Sie das ?


  • Der eigene Terminkalender wieder "rappelvoll" mit langen Meetings!
  • Sie kommen daher nicht dazu, Ihre Arbeit zu "in-time" erledigen
  • Sie finden keinen Platz im Terminkalender desjenigen, von dem Sie eine Entscheidung benötigen!
  • ....

Unbefriedigend, oder ?

Ich möchte hier kurz einen Ansatz vorstellen, der vielleicht hilft, die Lage etwas zu entspannen: "Das 15-Minuten-Meeting".

Zuvor möchte ich noch einen kurzen Überblick über das "Wesen" von Meetings geben. Im Anschluss finden Sie eine Zusammenfassung, vielleicht für Sie
nützliche Hinweise und Literraturangaben zum weiterlesen.

Ich wünsche viel Spaß beim "the 15-Minute-Meeting".

1. Was sind eigentlich Meetings ?

"Ein Meeting ist eine Zusammenkunft von zwei oder mehreren Menschen, zum Zweck, ein gemeinsames Ziel mittels verbaler Interaktion zu erreichen wie beispielsweise Informationen auszutauschen oder eine Entscheidung zu treffen" (Quelle: wikipedia)

Der Fokus bei Meetings liegt damit:
1. Entscheidungen zu treffen
2. zu informieren

Wenn es also in Meetings "nur" darum geht, Entscheidungen zu treffen oder zu informieren, dann müsste es doch möglich sein, diese kürzer und damit effektiver zu gestalten. Genau hier setzt das 15-Minuten-Meeting an.


2. Das 15-Minuten Meeting !

2.1. Die Agenda !

Lieben Sie Überraschungen ? Zum Geburtstag oder zu Weihnachten bestimmt, aber sicherlich nicht, wenn Sie etwas entscheiden sollen. Machen Sie sich, wenn Sie zu einem Meeting einladen, im Vorfeld genau Gedanken darüber, was das Ziel des Meetings sein soll und über was Sie entscheiden lassen oder informieren wollen.

2.2. Alle erforderlichen Teilnehmer !

Damit alle geplanten Entscheidungen in den 15 Minuten getroffen werden können oder umfassend informiert werden kann, müssen alle relevanten Entscheider oder Team-Mitglieder, die informiert werden sollen, "an den Tisch".
Das heisst im Umkehrschluss, dass die Teilnehmerliste nur so groß, wie unbedingt erforderlich ist (keine "me-too's" einladen).
Wer also keinen "Value-add" für das Meeting leisten kann, sollte nicht eingeladen werden.


2.3. Genau 15 Minuten ("time-boxed") !

Nicht mehr und nicht weniger. Innerhalb dieser 15 Minuten sind alle Punkte der Agenda zu besprechen. Zeit für "Politik" oder sonstige "Abschweifungen" bleibt damit nicht. Das Meeting findet absolut fokussiert auf sein Ziel statt!


2.4. "Next-Action" oder "Follow-Ups" !

15-Minuten-Meetings lassen keinen Raum für "blah-blah". Sie legen als Ergebnis die nächsten Schritte fest.
Daraus ergibt sich die Notwendigkeit, erweiterten Diskussionsbedarf oder das Abarbeiten der nächsten Schritte zu einem späteren Zeitpunkt durchzuführen.
Hierbei müssen aber nicht mehr alle Teilnehmer anwesend sein, sondern nur noch die, die für die jeweilige Aufgabe erforderlich sind.
Alle anderen können weiterarbeiten!


Das ist der große Produktivitätsvorteil der 15-Minuten-Meetings.


3. Summary

Das 15-Minuten-Meeting bietet einen großen Produktivitätsvorteil gegenüber "konventionellen" 1-2-Stunden-Meetings, da es:
  • time-boxed und
  • damit absolut fokussiert auf sein Ziel ist
  • nur die erforderlichen Personen "bindet"
  • mehr Meetings (und damit Entscheidungen) während eines Tages zulässt

4. Tipps

4.1 Für Entscheidungsmeetings
  • Bereiten Sie sorgfältig die Agenda vor
  • Machen Sie klar, was Sie mit dem Meeting erreichen wollen ("Ziel des Meetings ist, über die weitere Vorgehensweise bei XY zu entscheiden")
  • Weisen Sie in der Einladung darauf hin, dass sich die Teilnehmer auf das Meeting vorbereiten sollen, denn das Ziel haben Sie ja bereits klar definiert: Entscheidungen zu treffen und sich nicht während des Meetings in die Fakten einzuarbeiten.
    Dafür gibt es Workshops!
  • Verschicken Sie die erforderlichen Informationen rechtzeitig, so dass die Teilnehmer genügend Zeit haben, sich in die Fakten einzuarbeiten
  • Laden Sie nur die Teilnehmer ein, die einen "value-add" erzeugen werden
  • Halten Sie sich genau an die 15-Minuten-Regel! Keine Ausnahmen!!
  • Protokollieren Sie, was in dem Meeting besprochen wurde und versenden Sie es nach dem Meeting an die Teilnehmer
  • Halten Sie darin fest, wer, was, bis wann zu erledigen hat ("Next-Action" oder "Follow-Ups")

4.2 Für Informationsmeetings ("Status-Meetings")

Sie wollen sicherstellen, dass alle Team-Mitglieder über den aktuellen Status informiert sind und evtl. Hindernisse frühzeitig deutlich werden.
Hier bietet sich ein Teil der "Scrum"-Methode an.

Das sogenannte "Standup"

Im Standup beantwortet jedes Team-Mitglied die folgenden drei Fragen:
  1. Was habe ich seit dem letzten Standup ERLEDIGT (d.h. was ist fertig) ?
  2. Was werde ich bis zum nächsten Standup erledigen ?
  3. Was hat mich behindert, das zu erledigen, was ich mir vorgenommen habe ?

Vorteil des Standups ist, dass:
  • es auch bei größeren Teams problemlos in die 15 Minuten "passt"
  • jedes Teammitglied weiss, wo der andere gerade "steht"
  • evtl. Probleme schnell im gesamten Team "sichtbar" werden
  • dadurch ggf. kreative Lösungswege erst möglich werden

Wie wird ein Standup durchgeführt ?

  • täglich oder (spätestens) wöchentlich
  • ALLE STEHEN!!! (das Stehen stellt sicher, dass niemand in das "Sessel-Koma" fällt und deshalb nicht zuhört)
  • jedes Team-Mitglied beantwortet die drei Fragen (nicht mehr und nicht weniger; KEINE Romane!!)
  • die anderen Team-Mitglieder hören während dessen nur zu (keine Unterbrechungen des Redenden)
  • wenn das letzte Team-Mitglied gesprochen hat, ist das Standup beendet
  • Lösungen für evtl. Probleme oder Anmerkungen werden NACH dem Standup unter den Betroffenen diskutiert.
Alle anderen können wieder weiterarbeiten!


weiterführende Links:

Tuesday, May 17, 2011

Sind wir ein Team?

Das wir allen ein Team sind, ist allen klar, und Freunde sind wir übrigens auch...

Ist das wirklich so? Oder sagt man das so, weil man das so sagt? Wäre es unhöflich zu sagen wir wären kein Team, den wer nicht für uns ist, ist gegen uns, oder?

Was macht ein Team aus? Und was macht ein gutes Team aus?
Auf der Wikipedia Seite zum Begriff Team ist man sich einig das es keine einheitliche Definition und Verständnis vom Begriff Team gibt, einen Absatz bringt es aber für die Arbeitswelt auf dem Punkt:
Ein Team wird dann gebildet, wenn ein komplexes Verhalten eine interdisziplinäre Zusammenarbeit erfordert. Teams werden dabei für unterschiedliche Zwecke und Zielsetzungen mit unterschiedlicher zeitlicher Dauer gebildet. In diesem Sinne ist ein Team eine Gruppe von Mitarbeitern, die für einen ganzen, geschlossenen Arbeitsgang verantwortlich ist und die das Ergebnis ihrer Arbeit als Produkt oder Dienstleistung an einen internen oder externen Empfänger liefert.
(Quelle: wikipedia)

Bei Scrum ist das Team für das Sprintergebnis verantwortlich, starker noch, von den 3 Rollen die es bei Scrum gibt (Product Owner, Scrum Master und Team) ist das Team das einzige was einen direkten Mehrwert für das Projekt erzeugt, PO und SM sind "im management" tätig.

  • der Productowner managed das Product (und die Stakeholder)
  • der Scrummaster managed den Prozess
  • das Team managed sich selbst

Ein Team ist also gemeinsam für ein Ergebnis verantwortlich, was macht dan ein gutes Team aus, und woran erkent man ein gutes Team? Einige Teameigenschaften sind offensichtlich, und schnell genannt:
  • Kooperationsbereitschaft
  • Flexibilität
  • für einander einspringen
  • Schwächen kompensieren
  • Starken ausnützen
  • usw...

Alles Punkte die jeder von uns sofort unterschreiben würde, aber die Praxis seht meistens (unbeabsichtigt) anders aus. Was kann besser gemacht werden?

In einen Artikel "are you a whole team?" werden 4 "Gerüche" aufgezählt an die man ein gutes von ein optimal funktionierendes Team unterscheiden kann.
  • "Bestehen auf Stellenbezeichnung" in Gegensatz zu Argumentativer Überzeugungsarbeit, kann auch einfach nur ein extrem dominantes Teammitglied sein. 
  • "Held der Arbeit" gut gemeint, aber wenn das Team sich auf nur einer Person verlässt, wird dieser schnell zur Schwachstelle. Was passiert wenn dieser Mensch: Urlaub will? Krank wird? (vom Bus überfahren wird?)
  • "Am selben Platz bleiben" wer sich nicht bewegt, verändert sich nicht. Das Team sollte sich häufiger in 2-er Grüppchen neu Formieren um Aufgaben zu erledigen. (sehe Pair Programming und Pair Powerpointing)  
  • "der Außenseiter" tritt zumeist auf wenn die Fähigkeiten innerhalb des Teams sich stark unterscheiden. (zB: "zum Meeting gehen nur wir, der soundso kann mit Logistik sowieso nicht soviel anfangen")


Wer diese 4 Punkte im Auge behält, und aktiv gegensteuert sorgt dafür dass das Wissen in sein Team gut und gleichmäßig verteilt wird. Dies erhöht die Flexibilität und die Möglichkeit das Teammitglieder für einander einspringen können. Aber nicht nur reines Wissen, sondern auch best Practices, und Herangehensweisen werden so innerhalb des Teams weitergegeben und optimiert. Dies unterstützt die effektivste Möglichkeit der Produktivitätssteigerung:
"Work smarter, not harder!"
Abschlussfrage: "seid ihr ein Team?"

Wednesday, May 4, 2011

Projekt Management und GTD

Heute las ich den "Food For Thought" Newsletter von Dadvid Allen (Productive Living Newsletter)
David beschreibt das viele sich viel Zeit nehmen ihre Projekte zu organisieren, aber leider übersehen das Organisation nur einer von fünf gleich wichtige Phasen beinhaltet.
Häufig wird nach der Organisation sofort zum ausführen übergegangen, ohne die andere Phasen ausreichend zu beachten. Die fünf Phasen der Natural Planning Method sind:
  • Purpose (WAS versuchen wir WARUM?)
  • Vision (WIE seht FERTIG aus?)
  • Brainstorm (WAS könnten wir WIE tun)
  • Organise
  • Do
Keine Angst, es braucht nicht noch mehr Zeit zu kosten die andere vier Phasen ausreichend beachtung zu schenken. Die Zeit die in den ersten beiden Phasen zusätzlch investiert wird, zahlt sich in bessere und schnellere Ergebnisse die spätere Phasen durchaus aus. Wenn mann sich vorhet genauer klar wird WAS man machen möchte, wir dman auch genauer und effizienter organisieren können.
Es ist immer wieder erstaunlich wie sehr die Mehtoden Scrum und GTD in einander griefen. Ich denke sogar die Phasen passen eins zu eins aufeinander:
  • Purpose : Productbacklog
  • Vision : Definition of Done
  • Brainstorm : Sprintplanning I
  • Organise : Sprintplanning II
  • Do : Sprint
Auch bei Scrum hatte ich den Aufwand für das Productbacklog und Definition Of Done unterschätzt und ähnlich wie David beschreibt, mich vor allem auf Sprintplan und Sprint beschränkt. Das wird sich in Zukunft ändern, ich werde berichten.

agiles Universum - so wie ich es verstehe

Agiles überall

Hier mal eine schematische Darstellung wie die verschiedenen Ebenen der agilen Methoden einzuordnen sind. Viele methodische Ansätze sind den verschiedenen Verfahren gemein. Beispiele sind die Zieldefinition in GTD (siehe natural planning method - envision outcome) und SCRUM (how does the bright future look like) oder das bewerten und bepreisen von Aufgaben (storypoints in SCRUM).

Sunday, May 1, 2011

Leo Babauta: 38 Life Lessons I’ve Learned in 38 Years

Leo Babauta wurde vor ein paar Tage 38 Jahre alt. Zu sein Geburtstag beschreibt er 38 Dinge die er bisher im Leben gelernt hat.

Für jemand die einer der Thoughtleader im bereich des Minimalismus ist (sehe zB sein Buch: weniger ist mehr) sind 38 nicht gerade weing, und bestimmt nicht minimal, zumal eine Satz doppelt vor kommt.

Trotzdem interessant zu lesen, sowohl im Bezug auf wie wichtig es ist sich Zeit für seine Kinder zu nehmen, als auch in wie Weit man andere Beeinflüssen kann.
  • 11. You can’t motivate people. The best you can hope for is to inspire them with your actions.
Lesen, lernen, ausprobieren.
38 Life Lessons I've Learned in 38 Years

Friday, April 29, 2011

Eid der Untreue



Wie in der Einleitung angemerkt, es geht hier nicht darum das Rad neu zu erfinden. Daher:
Oath of Non- Allegiance by Alistair Cockburn:
"I'm tired of People from one school of thought dissing ideas from some other school of thought. I hunger for people who don't care where ideas come from, just what they mean ans what they produce."
http://alistair.cockburn.us/Oath+of+Non-Allegiance

Die Idee zu agiles-leben



Zu Doukumentationszwecken, das originale Mindmap vom 29. April 2011.