PROJEKT-LOG

Agile Werte Retrospektive

Robert Wiechmann — Mon, 19 Mar 2012 04:10:10 PDT

Manchmal ist es erforderlich und hilfreich, die agilen Prinzipien und Scrum Werte erneut in das Bewusstsein des Scrum Teams zu rücken. Justin Hennessey hat dazu kürzlich einen Beitrag verfasst. Darin schreibt er, dass es wichtig ist, sich dann und wann auf die agilen Werte zu besinnen. Ob nun ein „Reset“ bei einem Team, welches schon länger zusammenarbeitet oder bei einem jungen Team, dass die agilen Werte noch nicht verinnerlicht hat. Es kann verschiedene Gründe geben, um über die agilen Werte und Prinzipien zu sprechen. Die Besinnung, bspw. in einer Retrospektive, unterstützt ein Scrum Team dabei wertbasiert zu agieren. Die Retrospektive zeigt allen auf, welche Werte in welcher Ausprägung gelebt werden. Die Grundidee dieser Retrospektive entstammt von John Miller und kann immer wieder in Abständen angewandt werden.

Im Folgenden möchte ich eine Retrospektive von ca. 60 Minuten vorstellen, wie ich sie mit einem Team von 8 Personen durchgeführt habe. Für die Durchführung von Retrospektiven verwende ich das Schema von Esther Derby und Diana Larsen. Dieses teilt das Event in fünf Phasen ein.

Startphase

Zu Beginn ist es sinnvoll kurz zu erörtern, warum diese Art der Retrospektive gewählt wurde. Nach der kurzen Einleitung und der Überprüfung der Agenda werden die Teilnehmer mit der Bitte um die Beantwortung einer Frage, auf das Thema eingestimmt. Diese Aktivität heißt „Check-in“ und verlangt von den Teilnehmern die Beantwortung einer Frage in einem kurzen Satz oder wenigen Wörtern. Beispielsweise sind die Anwesenden aufgefordert, die Frage „Nenne kurz ein Beispiel, welches agile Prinzip du im letzten Sprint angewendet hast?“ oder „Sage in wenigen Worten, was du dir von der Retrospektive erhoffst?“ der Reihe nach zu beantworten.

Nachdem die Runde beendet ist, kann zum eigentlichen Thema übergeleitet werden. Es ist am Anfang hilfreich einen Exkurs mit dem Team zu machen und noch einmal die 12 Prinzipien des Agilen Manifests vorzustellen. Dies kann auch spielerisch gestaltet werden, indem man zusammen die agilen Prinzipien anhand von praktischen Beispielen entdeckt. Auf jeden Fall sollte die Teilnehmer aktiv mit einbezogen werden. Wichtig ist es hier, auf den Zeitrahmen zu achten.

Informationen zusammentragen und Einsichten generieren

Nach dieser Einführung kann nun auf die Team Werte wie bspw. „Focus“, „Commitment“, „Respect“, „Openness“ und „Courage“ eingegangen werden. Der Scrum Master fängt danach an, einen Wert zu nennen und in die Runde zu fragen „Was meint ihr, wie leben wir diesen Wert?“ Danach bittet er die Teammitglieder anhand von Planning Poker Karten oder mit Anzeigen von Fingern diesen Wert einzuschätzen. Wenn es bei der Bewertung große Abweichungen gibt, dann sind die beiden am weitesten auseinander liegenden Bewertungen (beispielsweise 5 und 1) danach zu fragen, warum sie den Wert so einschätzen. Hier kann man die Diskussion ein wenig laufen lassen. Nachdem nun die anderen Teammitglieder diese Informationen hören konnten, wird die Einschätzung des Wertes wiederholt. Soweit es immer noch minimale Abweichungen gibt (zum Beispiel zwischen 4 und 5) sollte der niedrige Wert genommen werden. Der Scrum Master notiert nun das Ergebnis am agilen Wert. Dies wird nun für jeden agilen Wert durchgespielt, bis alle Werte vom Team eingeschätzt wurden.

Durch das Schätzverfahren kommt man recht schnell zu einem Ergebnis und Konsens innerhalb der Gruppe. Richtig spannend sind jedoch die Diskussionen und Wahrnehmungen der einzelnen Teilnehmer. Diese geben dem Scrum Master wertvolle Hinweise über den Fortschritt seiner Arbeit und die Gelegenheit, Schwachpunkte oder Verständnisprobleme zu lokalisieren und Stärken des Teams zu unterstützen.

Entscheidung herbeiführen

Nach dieser Runde, stellt der Scrum Master dann die Frage „Welchen dieser Werte wollt ihr bis zur nächsten Retrospektive verbessern?“ Auch hier kann man sich wieder einer einfachen Abstimmung per Handzeichen bedienen oder ein Bewertung durch Punkte vornehmen. Nachdem feststeht, welcher Wert angegangen werden soll, stellt der Scrum Master dem Team folgende Frage „Was ist die eine konkrete Verbesserung, die ihr euch vornehmen wollt?“

Es geht hier wirklich um die Besinnung auf die Auswahl einer Aktivität. Es steht dem Team jetzt Zeit zur Verfügung, die Themen zu diskutieren und die Verbesserung zu überlegen. Am Ende sollte das Ergebnis ein Statement sein, welches in die Form

„Wir glauben an den Wert [X] und nehmen uns daher vor [was wir tun wollen].“

Das Team Statement sollte nun vom Team unterschrieben werden und federführend ein Freiwilliger für das Vorantreiben der Realisierung gefunden werden.

Endphase der Retrospektive

Am Ende der Retrospektive sollten die gewonnen Erkenntnisse zusammengefasst und das Team um Feedback zur Retrospektive gebeten werden. Für das Resümee pointiert der Moderator die wichtigsten Punkte der Diskussionen, die er sich im besten Fall während der Abstimmungsdiskussion notiert hat. Das festgelegte Statement des Teams wird später im Teamraum sichtbar aufgehängt. Auch alle anderen Werte finden dort Platz. Die Informationen zu den Agilen Prinzipien können zusammengefasst an die Teilnehmer zu Informationszwecken, inklusive der Erkenntnisse aus den Diskussionen, versendet werden.

Great minds discuss ideas, average minds discuss events, small minds discuss people. [Unbekannt]

Robert Wiechmann — Thu, 01 Mar 2012 23:00:40 PST

Scrum Einführung in unter 10 Minuten

Robert Wiechmann — Sat, 25 Feb 2012 23:00:24 PST

Sehenswertes Video indem Scrum anschaulich vorgestellt wird.

www.axasoft.com promotet damit das online Tool “onTime”.

Versuchs mal Feature-Driven

Katja Roth — Thu, 23 Feb 2012 22:00:47 PST

Das Team sitzt im Sprint Planning 2 zusammen und befasst sich mit der Frage, wie die im Sprint Planning 1 gezogenen User Stories umgesetzt werden sollen. Es klärt die technischen Details, stellt architektonische Fragen und schreibt das, was zu tun ist als Tasks auf Karteikarten. Typische Tasks sind: “Controller anpassen” oder “Service schreiben”.

Nun beginnt der Sprint. Zwei Teammitglieder ziehen den Task “Controller anpassen”. Im Daily Scrum berichten sie am folgenden Tag darüber, was sie schon alles am Controller verändert haben und dass sie noch einen weiteren Tag benötigen, um die Arbeit zu beenden. Andere Teammitglieder wundern sich, warum dieser Task so viel Zeit in Anspruch nimmt, erinnern sich aber auch nicht mehr daran, was im Sprint Planning 2 zu diesem Task vereinbart wurde. Am Ende des Sprints ist die User Story nicht fertig, weil auch bei den anderen Tasks nicht klar war, was konkret getan werden sollte.

Eine Veränderung musste her. Aber was kann man also tun, um den Umfang eines Tasks besser zu umreißen? Das Team entscheidet sich zu einer radikalen Veränderung. Künftig soll es keine technischen Tasks mehr geben. Stattdessen setzt das Team auf ein feature-getriebendes Vorgehen. Und so sieht das dann aus: zunächst klärt das Team für jede User Story anhand der Akzeptanzkriterien, welche manuellen und automatischen Tests notwendig sind. So findet es heraus, ob es Unstimmigkeiten in den Akzeptanzkriterien gibt und ob die Story vollständig verstanden wurde. Dann wird jede User Story in aufeinander aufbauende Mini-Features zerlegt, die schrittweise umgesetzt werden sollen. Ein typischer Task lautet: “Straße und Hausnummer erfassen”. Um die technische Umsetzung nicht komplett aus den Augen zu verlieren, führt das Team für jede Story einen Code Dive durch (schaut sich also die betroffenen Stellen im Code an). So gelingt es die Eckpfeiler der technischen Realisierung festzulegen, was schließlich zentrale Aufgabe im Sprint Planning 2 ist.

Nach einigen Sprints kann das Team dieses Fazit ziehen: mit Feature Driven Development ist das Ziel jedes Tasks klar umrissen und das Team verzettelt sich nicht mehr bei der Umsetzung. Außerdem gibt es einen weiteren, wenn auch ungeplanten, positiven Nebeneffekt. Spezialisten, wie Frontendentwickler sind jetzt deutlich besser in das Team integriert. Sie bearbeiten nicht mehr den Task “Frontend erstellen”, da von jetzt an (fast) jeder Task einen Frontend-Anteil hat. Stattdessen arbeitet der Frontend-Experte jetzt interdisziplinär an allen Tasks mit. Durch die Vorab-Festlegung der Testfälle hat das Team außerdem ein deutlich besseres Verständnis der User Stories erreicht.

Versuchen Sie es doch auch einmal feature-getrieben!

Magst du es ebenso wie ich, zu sehen wie Dinge fertig werden?

Susanne Reppin — Fri, 17 Feb 2012 23:00:35 PST

Ich mag Übersichtlichkeit. Aber noch lieber sehe ich zu, wie Dinge voran kommen und fertig werden. Ich mag “Fertig-Häkchen” und das Gefühl wirklich Sachen zu machen, zu erledigen oder zu gestalten, wie zum Beispiel Coaching, Konzepte, Lösungen finden, Pläne machen oder Ideen generieren. Einfach nur einen Überblick darüber zu haben “Was sollte ich noch machen?” frustriert mich. Ich möchte Dinge nicht sehen bevor ich Zeit habe sie zu tun und trotzdem möchte ich das Gefühl haben sie nicht zu vergessen.

Der Sinn eines Überblicks ist ein Blitzlicht zu machen, auf einen Augenblick der Realität. Aber ich möchte solch ein Blitzlicht auf die Realität nicht jeden Tag und schon gar nicht wenn noch weitere Menschen, Gruppen oder Teams involviert sind. Ich denke das ist weggeworfene Zeit ohne Zufriedenheit zu erzeugen (sprich “waste”). Das passiert in manchen Team Stand-ups. Eine Menge Leute stehen herum, sprechen, hören zu und sind gelangweilt. Das Ergebnis ist genau das, was sie nicht wollten: Es macht unglücklich und frustriert, jeden Tag dieselben Dinge dort hängen zu sehen, die eigentlich umgesetzt werden sollten.

Die Idee von Kanban und agilen Teams ist es herauszufinden, wie wir etwas machen (mit „wir“ sind die Teams gemeint, die ich coache). Die Idee ist die Zufriedenheit zu verbessern und den effizienten und glücklich machenden “flow”, die Dinge fließen zu lassen, zu entwickeln. Die Idee ist herauszufinden, welcher der richtige Weg für uns ist, Ziele zu erreichen. Wir möchten Dinge fertigstellen. Wir möchten planen, Konzepte machen und mit großen Aufgaben gut und locker umgehen. Meine Empfehlung hier ist, lasst das Team den richtigen Prozess finden, um den Flow zu spüren und um Spaß zu haben.

Was können wir tun, um Team boards von agilen Teams effizient zu machen?

Fragt euch, ob der Inhalt der Karten, die aktuell wichtigen Dinge für die Teammitglieder enthalten. Fokussiert euch und übernehmt zuerst einmal keine Nebenaufgaben.
Spielt mit dem “Work-in-Progress Limit” (WIP), so dass Sicherheit darüber besteht, dass es weh tut, wenn das Team nicht genug zusammenarbeitet. Dies erzeugt einen Wissenstransfer und führt zu einer verbesserten Qualität (durch bspw. Pair-Programming).
Vergeudet keine Zeit mit der Beantwortung von Fragen wie “Ist diese Aufgabe gut genug, um eine Karte zu schreiben?”. Schreibt sie einfach, hängt sie ans Board und testet es aus, ob es sich als hilfreich erweist.
In regelmäßigen Abständen sollten die Karten, die auf die Übernahme in die “Soon”-Queue warten, besprochen werden. Dies gibt allein einen Gesamtüberblick und ein sicheres Gefühl, alles im Blick zu haben.
Vergeudet keine Zeit in langen Diskussionen, ob eine Karte fertig ist. Hängt die Karte einfach in die „Done“-Spalte am Board und schreibt neue Karten mit all den Dingen, welche noch getan werden müssen. Ein noch besserer Weg ist es zu definieren, wann Karten generell für ein Team als “fertig” gelten. Dies tut man unter Zuhilfenahme von Akzeptanzkriterien, die für jede Karte einzeln definiert werden.

Die beschriebenen Hebel sollen zum Wachrütteln dienen, um darüber nachzudenken was ihr macht.

Manchmal versuche sogar ich selbst, eine Methode anzuwenden, nur weil ich denke ich sollte. Häufig wäre es aber besser damit aufzuhören, um nicht weiter Zeit und Energie zu vergeuden. Das könnte dann eine wirkliche Verbesserung sein. Agil zu leben, zu fühlen und zu agieren bedeutet auch die Dinge, die Umstände, mein eigenes Tun zu betrachten und zu überprüfen wo es Sinn machen könnte Hebel umzulegen, um sich zu verbessern.

Besser kommunizieren

Robert Wiechmann — Wed, 11 Jan 2012 22:00:27 PST

Tipps zu Präsentationen werden auch in diesem Jahr Thema dieses Blogs sein. Es gibt einfach zu viele schlechte Präsentationen und zu wenige gute Redner. Hier ein lustiges Beispiel, wie wir es alle kennen, aber nicht mehr sehen wollen…

via www.blogpiloten.de

Product Owner im Potrait: Niklas Sum

Robert Wiechmann — Sun, 08 Jan 2012 21:40:27 PST

Den ersten Artikel des Jahres widmen wir Niklas Sum, der momentan als Product Owner bei www.betterplace.org tätig ist. Nach seinem Studium der Betriebswissenschaft arbeitete er bis 2009 bei SportScheck in München. Seit Januar 2010 unterstützt er das Produktmanagement bei betterplace.org in Berlin. Privat ist der Umweltschutz eines der zentralen Anliegen von Nicklas, der unter anderem das Projekt www.energie-ohne-zukunft.de auf die Beine gestellt hat. Als Product Owner ist er dort für die Weiterentwicklung der Website zuständig, an der täglich mit einem Scrum Team gearbeitet wird. Niklas beschreibt im Interview, wie sein Tagesgeschäft bei betterplace.org aussieht, welche Herausforderungen auf ihn warten und gibt hilfreiche Tipps, die für die Arbeit in der Rolle als Product Owner hilfreich sind.

Steckbrief

Name: Niklas Sum
Alter: 25
Angestellt als: Produktmanager
Product Owner Rolle seit: 2011
Berufserfahrung gesamt: 2,5 Jahre
Branche: Internet, e-Commerce
Produkt Thema: betterplace.org – Spendenplattform und Marktplatz für soziales Engagement

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

Das Schwierigste ist häufig das Setzen von Prioritäten. Auf der einen Seite stehen die Stakeholder mit sehr vielen guten Ideen, auf der anderen Seite ein relativ kleines Entwicklerteam. Hier die richtige Entscheidung zu treffen, was auf die Product Roadmap kommt, in der “Icebox” landet oder auf die ganz lange Bank geschoben wird, ist essentiell.

Was sind deiner Meinung nach die wichtigsten Fähigkeiten eines Product Owners?

Die Markt- und Wettbewerbssituation sollte man abstrahieren und die gewonnen Informationen auf das Produkt anwenden können. Man muss in angebrachtem Maße eine Liebe zum Detail haben, darf dabei aber nicht den Gesamtüberblick verlieren.

Welche Softskills sollten bei einem Product Owner besonders ausgeprägt sein?

Ein Product Owner muss sehr kommunikationsstark sein, denn er ist Bindeglied zwischen allen Stakeholdern. Er muss mit allen auf einer Augenhöhe kommunizieren können und so viel Empathie besitzen, sich auf die unterschiedlichsten Menschen einzulassen. Er muss nicht nur in Meetings überzeugen können, sondern immer ein offenes Ohr für Jedermann im gesamten Team zu haben: Welche Bedürfnisse, Probleme oder Wünsche gibt es?

Welche Rolle spielt das Entwicklungsteam bei der Erfüllung deiner Aufgaben?

Meine Aufgabe ist es, Produkte und Anforderungen zu liefern, die valuable, feasible und usable sind. Das geht nur in enger Zusammenarbeit mit dem Entwicklungsteam. Scrum stellt das Team vor die Herausforderung, dass es keine seitenlangen Spezifikationen gibt, die es abzuarbeiten gilt, sondern sehr viel der Konzeptions- und Spezifikationsarbeit in der direkten Kommunikation erledigt wird. Darauf müssen sich alle im Scrum Team einlassen, um erfolgreich zusammenarbeiten zu können.

Wie grenzt sich deine Arbeit von der des Scrum Masters ab?

Wir arbeiten bei betterplace seit 1,5 Jahren ohne einen dedizierten Scrum Master und hatten lediglich zur Einführung des Scrum-Prozesses den Luxus eines Vollzeit-Scrum Masters. Daher sind bei uns die Grenzen ein wenig fließend. Wir alle (PO und Entwicklungsteam) schauen gemeinsam darauf, dass der Prozess eingehalten wird, hauen uns gegenseitig auf die Finger und beseitigen Impediments gemeinsam. Geholfen hat uns hier u.a. die Einführung eines „Artefakts”. Zum Beispiel wird einer der Entwickler während des Stand-ups in die Rolle des Scrum Masters befördert. Mit solchen Hilfsmitteln und einem erfahrenen und eingespielten Team ist Scrum meiner Meinung nach auch ohne dedizierten Scrum Master machbar.

Wie organisierst du deine Arbeit, um die fortlaufende Erstellung von Backlog Items aufrecht erhalten zu können?

Zu Beginn eines neuen Backlog Items steht meistens ein Gespräch mit einem Stakeholder oder eine E-Mail. Mehr als eine User Story ist es dann meistens noch nicht. Je näher die Story dann in Richtung Umsetzung kommt, desto konkreter und ausführlicher wird sie beschrieben. Hilfreich sind hier die fest eingeplanten Estimations und Plannings, da hier immer mehr Informationen benötigt werden, um die Story konkreter zu machen.

Scrum stellt hohe Ansprüche an die Rolle des Product Owners. Sind diese deiner Meinung nach zu erfüllen bzw. wo liegen die Herausforderungen?

Ich denke durchaus, dass die Ansprüche zu erfüllen sind. Klar sollte sein, dass es kein 9to5-Job ist, sondern man das Produkt leben und lieben sollte, um erfolgreich zu sein. Eine Herausforderung ist sicherlich, den Wald vor lauter Bäumen nicht mehr zu sehen: viele Meetings, Stories für die immer laufenden 2-wöchigen Sprintzyklen vorbereiten und das Entwicklerteam betreuen.

Welche Unterstützung hilft dir am meisten bei der Erledigung deiner Aufgaben?

Zuerst natürlich das Entwicklerteam, mit dem eine sehr gute Zusammenarbeit erforderlich ist. Tools die ich zur Organisation meiner Aufgaben verwende sind hauptsächlich Pivotaltracker und Things.

Um Product Owner zu werden, lassen sich viele zertifizieren. Ist es deiner Meinung nach damit getan? Was hat dir geholfen, die Rolle auszufüllen?

Ich habe ebenfalls eine zertifizierte Scrum-Schulung besucht. Nicht, um das Zertifikat zu bekommen, sondern vielmehr, um mehr über die Rolle des Product Owner zu erfahren und zu lernen. Damit ist es allerdings auf keinen Fall getan, es hilft aber andere Product Owner kennenzulernen und über mögliche Probleme zu sprechen und Lösungswege zu diskutieren.

Du kennst die Praxis am Besten – Was sind die 3 schlimmsten Fehler, die man als Product Owner machen kann?

Selber keine Ahnung haben, was die Anforderungen sind oder unvorbereitet in ein Planning/Estimation gehen.
Die Meinung des Anwenders ignorieren – Stichwort Usertesting.
Die Meinung des Entwicklerteams nicht respektieren.

Kann aus deiner Sicht jeder die Rolle des Product Owners besetzen? Wenn nein, warum nicht?

Man muss auf jeden Fall Druck aushalten können und bereit sein, viel Verantwortung zu übernehmen. Man steht 100 Prozent für den Erfolg des Produkts. Trotzdem muss man in der Lage sein, sich unterordnen zu können. Hilfreich ist außerdem, technisches Wissen zu haben, um bei Bedarf Diskussionen im Entwicklerteam über mögliche technische Lösungen mitgestalten zu können.

Backlog Grooming ist ein essentieller Bestandteil von Scrum. Was sind deine Erfolgsfaktoren für die richtige Anwendung?

Das Backlog Grooming ist fester Bestandteil des Terminkalenders und geschieht in ruhiger Stunde vor den Estimation Meetings. Die Sortierung entsteht dabei grob anhand der Roadmap und des Business Values. Erst wenn eine erste Sortierung steht, neue Bugs eingetragen und andere Stories rausgeflogen sind, werden die Items mit dem gesamten Team in Estimation Meetings besprochen und geschätzt.

Was waren die größten Herausforderungen nach dem Wechsel zu Scrum und der Übernahme der Rolle als Product Owner?

Scrum und die Organisation unter einen Hut zu bringen und zum Laufen zu bringen, war sicherlich die größte Herausforderung für unsere Organisation. Die Rolle als Product Owner habe ich übernommen, nachdem ich schon ein Jahr Teil des Entwicklungsteams war. Probleme, das Standing sich erst noch erarbeiten zu müssen, hatte ich Dank meiner tollen Kollegen nicht.

Erzähl doch bitte aus deiner Praxis – Wie gestaltet sich ein normaler Arbeitstag für dich?

Der Tag beginnt mit Emails lesen, Termine und Aufgaben überfliegen, KPI’s checken sowie Küchengesprächen. Danach folgt um 9.30 Uhr das tägliche Stand-up mit dem Entwicklungsteam. Das war’s dann aber auch schon mit der Gleichförmigkeit. Danach folgen unterschiedliche Termine mit Stakeholdern über laufende und zukünftige Projekte oder innerhalb des Produktteams zu Themen wie bspw. Konzept oder Design. Gleichzeitig steht die Tür zu den Entwicklern fast immer offen – bereit für etwaige Rückfragen.

Was ist deine Empfehlung für diejenigen die mit dem Gedanken spielen die Rolle zu übernehmen bzw. die ihre ersten Schritte in der Rolle als Product Owner machen?

Wichtig ist die Entscheidung, ob man bereit ist, so viel Verantwortung zu übernehmen. Darüber hinaus sollte man sich so sehr mit dem Produkt identifizieren können, dass man es in allen Belangen gerne repräsentiert. Wichtige Grundeigenschaften wie Kommunikationsstärke und Belastbarkeit habe ich ja schon im ersten Teil des Interviews herausgestellt. Für die ersten Schritte ist der Kontakt zu anderen (erfahreneren) Product Ownern ratsam, um auftauchende Probleme zu besprechen.

Frohe Weihnachten

Robert Wiechmann — Thu, 22 Dec 2011 23:58:09 PST

Der Gewinner des Gewinnspiels aus letzter Woche wurde ermittelt und von mir kontaktiert. Er darf sich über ein handsigniertes Buch “Management 3.0” von Jurgen Apello freuen. Herzlichen Glückwunsch!

An dieser Stelle möchte ich die Gelegenheit nutzen Sven Röpstorff, Susanne Reppin, Katja Roth und Ralf Wirdemann für Ihre Mitarbeit und Fachbeiträge recht herzlich zu danken. Mein Dank gilt auch allen Interviewpartnern für die aufschlussreichen Einblicke in ihren Arbeitsalltag.

Vielen Dank allen neuen und treuen Lesern, die auch in 2012 interessante Beiträge erwarten können.

Ich wünsche eine frohe Weihnacht und einen Guten Rutsch in das Neue Jahr!

Jahresrückblick 2011 plus Gewinnchance

Robert Wiechmann — Tue, 13 Dec 2011 22:00:39 PST

Kaum kommt man aus dem lang ersehnten Jahresurlaub zurück, da neigt sich das Jahr auch schon dem Ende zu. Für mich war es ein sehr arbeitsreiches Jahr, welches zügigen Schrittes auf das Jahresende zugegangen ist. Ich habe viel meiner privaten Zeit der Fortführung des Blogs gewidmet, neue Dinge ausprobiert und an weiteren Ideen gearbeitet. Die Arbeit mit meinen Teams hat mir auch in diesem Jahr viel Freude bereitet und ich konnte allerhand dazu lernen. Ich freue mich auf 2012, mit seinen neuen persönlichen, fachlichen und menschlichen Herausforderungen. Nachfolgend einige Zahlen, wie sich projekt-log.de in 2011 weiterentwickelt hat, inklusive Weihnachtsgewinnspiel.

Projekt-log.de im Jahresrückblick:

Dieses Jahr wurden 60 Artikel zu den verschiedensten Fachthemen verfasst, also im Schnitt 1 Artikel pro Woche.
Knapp 23.000 Besucher (2010: 14.500) haben an die 36.700 Seitenaufrufe (2010: 27.100) getätigt.
Am 8.11.2011 war der meistbesuchte Tag mit 248 Besuchern.
Die meisten Besucher kommen aus Deutschland, gefolgt von der Schweiz, Österreich sowie den USA.
Katja Roth ist im April als neue Autorin gestartet.
projekt-log.de ist im Mai zwei Jahre alt geworden.
Im Laufe des Jahres haben wir auf Zweisprachigkeit umgestellt und bieten seit diesem Zeitpunkt viele Artikel auch in Englischer Sprache an.
tools.projekt-log.de erblickte das Licht der Welt und wird im kommenden Jahr weiter ausgebaut.
Das persönliche Engagement, Zeit und Energie der Autoren: unbezahlbar.

Die Top 5 Artikel aus 2011:

Das Beste zum Schluß

Ich verlose ein handsigniertes Exemplar des Buches Management 3.0 von Jurgen Appelo.

So einfach gehts: Jeder der ab heute den “Gefällt-mir“-Button auf Facebook drückt oder @projekt_log auf Twitter folgt, ist bei der Verlosung des Buches dabei. Der Gewinnspielzeitraum endet mit Ablauf des 21.12.2011. Am 22.12. werde ich die Auslosung vornehmen und den Gewinner kontaktieren. Der Gewinn sollte dann noch rechtzeitig zum Weihnachtsfest eintreffen. Viel Glück!

Meine Pünktlichkeit drückt aus, dass mir deine Zeit so wertvoll ist wie meine eigene. [Helga Schäferling]

Robert Wiechmann — Sun, 11 Dec 2011 00:38:19 PST

PROJEKT-LOG

Agile Werte Retrospektive

Startphase

Informationen zusammentragen und Einsichten generieren

Entscheidung herbeiführen

Endphase der Retrospektive

Weitere Artikel zu diesem Thema

Great minds discuss ideas, average minds discuss events, small minds discuss people. [Unbekannt]

Weitere Artikel zu diesem Thema

Scrum Einführung in unter 10 Minuten

Weitere Artikel zu diesem Thema

Versuchs mal Feature-Driven

Weitere Artikel zu diesem Thema

Magst du es ebenso wie ich, zu sehen wie Dinge fertig werden?

Was können wir tun, um Team boards von agilen Teams effizient zu machen?

Weitere Artikel zu diesem Thema

Besser kommunizieren

Weitere Artikel zu diesem Thema

Product Owner im Potrait: Niklas Sum

Steckbrief

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

Was sind deiner Meinung nach die wichtigsten Fähigkeiten eines Product Owners?

Welche Softskills sollten bei einem Product Owner besonders ausgeprägt sein?

Welche Rolle spielt das Entwicklungsteam bei der Erfüllung deiner Aufgaben?

Wie grenzt sich deine Arbeit von der des Scrum Masters ab?

Wie organisierst du deine Arbeit, um die fortlaufende Erstellung von Backlog Items aufrecht erhalten zu können?

Scrum stellt hohe Ansprüche an die Rolle des Product Owners. Sind diese deiner Meinung nach zu erfüllen bzw. wo liegen die Herausforderungen?

Welche Unterstützung hilft dir am meisten bei der Erledigung deiner Aufgaben?

Um Product Owner zu werden, lassen sich viele zertifizieren. Ist es deiner Meinung nach damit getan? Was hat dir geholfen, die Rolle auszufüllen?

Du kennst die Praxis am Besten – Was sind die 3 schlimmsten Fehler, die man als Product Owner machen kann?

Kann aus deiner Sicht jeder die Rolle des Product Owners besetzen? Wenn nein, warum nicht?

Backlog Grooming ist ein essentieller Bestandteil von Scrum. Was sind deine Erfolgsfaktoren für die richtige Anwendung?

Was waren die größten Herausforderungen nach dem Wechsel zu Scrum und der Übernahme der Rolle als Product Owner?

Erzähl doch bitte aus deiner Praxis – Wie gestaltet sich ein normaler Arbeitstag für dich?

Was ist deine Empfehlung für diejenigen die mit dem Gedanken spielen die Rolle zu übernehmen bzw. die ihre ersten Schritte in der Rolle als Product Owner machen?

Weitere Artikel zu diesem Thema

Frohe Weihnachten

Ich wünsche eine frohe Weihnacht und einen Guten Rutsch in das Neue Jahr!

Weitere Artikel zu diesem Thema

Jahresrückblick 2011 plus Gewinnchance

Projekt-log.de im Jahresrückblick:

Die Top 5 Artikel aus 2011:

Das Beste zum Schluß

Weitere Artikel zu diesem Thema

Meine Pünktlichkeit drückt aus, dass mir deine Zeit so wertvoll ist wie meine eigene. [Helga Schäferling]

Weitere Artikel zu diesem Thema