In der Vergangenheit habe ich oft über die Vorteile von Scrum aus Sicht des Teams geschrieben. Aber das ist sozusagen nur die halbe Wahrheit. Ein anderer, wichtiger, Aspekt wird nämlich oftmals übersehen:

Auch für das Management hat Scrum einige handfeste Vorteile!

mehr »

Beim letzten Agile Tuesday, dem Stammtisch der Münchner Scrum-Community, hatte ich eine interessante Diskussion zum Thema “Was ist eigentlich ein Team?”.

Meiner Meinung nach darf man eine Gruppe von Personen nur dann zurecht “Team” nennen, wenn es sich dabei um ein selbstorganisierendes Team handelt. D.h., das Team darf frei über seine (interne) Organisation entscheiden. Der Preis dafür ist jedoch Verantwortung, v.a. für das Erreichen des (gewünschten) Projektergebnisses.

mehr »

Eines der wichtigsten Konzepte in Scrum sind “Sprints”. Sprints sind Iterationen fester Länge, an deren Ende ein potentiell auslieferungsfähiges Produktinkrement steht.

Es wird zwar noch nicht den kompletten Funktionsumfang aufweisen. Diejenigen Anforderungen, die bereits umgesetzt wurden, sind jedoch schon auf einem Stand, an dem man sie auch an Endkunden verkaufen könnte. Dies bedeutet, daß alle in einem Inkrement enthaltenen Anforderungen als “fertig” (engl. “done”) betrachtet werden können.

Doch was genau bedeutet denn nun “fertig”?

mehr »

Es ist jetzt ungefähr ein dreiviertel Jahr her seitdem wir unser Scrum-Poster veröffentlicht haben. Damals teilweise noch als Experiment gedacht, haben uns die vielen positiven Rückmeldungen doch etwas überrascht. Auch hatten wir mit einem solchen Erfolg nicht unbedingt gerechnet:

Insgesamt wurde es mehr als 2500 mal heruntergeladen, zudem haben wir noch eine ganze Menge an gedruckten Exemplaren verteilt. Wie damals bereits angekündigt wurde das Plakat seitdem stetig weiterentwickelt. Irgendwann jedoch wurde es wieder Zeit, diese Gedanken festzuhalten und in ein neues Plakat zu transformieren. Heute nun sind wir endlich soweit, die zweite Version unseres Scrum-Plakates präsentieren zu können. mehr »

In meinem letzten Artikel habe ich einen kleinen Vergleich zwischen Scrum und Kanban angestellt und einige Gemeinsamkeiten und Unterschiede zwischen den beiden Methoden aufgezeigt. Diesen Vergleich möchte ich dieses Mal gerne fortführen und einige weitergehende Punkte beleuchten. Darunter u.a. die Verteilung von Kanban-Tafeln auf Teams und der Arbeit an mehreren Produkten zur selben Zeit.

Dieser Artikel baut auf dem vorherigen auf. Sollten Sie den ersten Teil des Artikels bisher noch nicht gelesen haben, so wäre es daher nicht verkehrt dies noch nachzuholen, bevor Sie weiterlesen.

Wie im ersten Teil erwähnt durchläuft ein Scrum-Board im Laufe einer Iteration immer wieder denselben Zyklus, und wird am Ende der Iteration wieder zurückgesetzt. Dies hat als Konsequenz, daß eine Anforderung, die mittels Scrum realisiert wird, nicht länger dauern darf als der Sprint lang ist. Grössere Happen müssen also in mehrere kleine aufgeteilt werden.

mehr »

In der letzten Zeit höre ich öfter etwas über Kanban. Oft auch verbunden mit der Frage “macht ihr noch Scrum, oder seid ihr schon auf Kanban umgestiegen?”.

Teilweise hat man den Eindruck, Kanban sei so etwas wie der „Nachfolger” zu Scrum.
Dem ist jedoch nicht so. Ganz im Gegenteil. Beide basieren auf denselben Ideen. Ein ausführlicher Vergleich findet sich z.B. hier. Damit Sie dort nicht alles im Detail nachlesen müssen, hier eine kurze Zusammenfassung.

mehr »

Am 6. Mai 2009 fand in München zum ersten Mal der “ScrumDay” statt, zeit- und ortsgleich mit der “TeamConf”, einer Konferenz zum Thema “Microsoft Visual Studio Team System”.

Der Tag begann mit einer Keynote von Ken Schwaber, einem der “Erfinder” von Scrum, zum Thema “Scrum, But …”. Er gab eine kurze Einführung in das Thema Scrum und die dahinter liegenden Werte (Selbstorganisation, Transparenz, Integrität).

Zudem stellte er noch klar, daß Scrum empirische Softwareentwicklung bedeutet, da man in regelmäßigen Abständen auf die Projektsituation blickt und, so notwendig, Anpassungen vornimmt. Er verglich es mit dem Temperaturfühler einer Klimaanlage, der in regelmäßigen Abständen die Temperatur eines Raumes überprüft und bei Abweichungen die Anlage höher oder niedriger stellt.

Eine solche Vorgehensweise wird nötig, da die Komplexität heutiger Softwareentwicklungsprojekte zu hoch ist um alles zu überblicken (länger als 4 Wochen sowieso nicht). Zudem ändert sich erfährungsgemäß sowieso 35% eines Projektes im Laufe der Zeit.

mehr »

Natürlich gibt es die Folien auch in der “Technischen Ecke” auf der Seite Dokumente im IF-Blog.

Die Idee hinter Scrum war nicht nur, Projekte erfolgreich abzuschließen, d.h. Zeit, Qualität und Budget einzuhalten ( obwohl das für sich alleine natürlich schon ein hehres Ziel wäre).

Es sollte darüber hinaus auch die Produktivität im Vergleich zur bisher eingesetzten Projektmanagementmethode auf einen neuen Level gehoben werden.

Eine Möglichkeit dazu wurde von Jeff Sutherland auf der Konferenz “Agile 2005″ beschrieben (nachzulesen hier). Sein Ansatz basiert im wesentlichen auf einer Arbeit von Nonaka und Takeuchi, die 1984 im “Harvard Business Review” erschienen ist (siehe hier).

Darin beschreiben die beiden Autoren die Art und Weise, wie verschiedene japanische Firmen im Vergleich zu amerikanischen Firmen ihre Produkte entwickeln.

mehr »

Im ersten Teil dieses Artikels habe ich ein wenig über den grundsätzlichen Aufbau einer Retrospektive erzählt und dabei folgende 5 Schritte vorgeschlagen:

1. Voraussetzungen schaffen
2. Daten sammeln
3. Einsichten generieren
4. Entscheide, was zu tun ist
5. Schließen der Retrospektive

Um jedoch zu einem möglichst guten Ergebnis zu kommen ist eine solche Agenda alleine natürlich noch nicht ausreichend. Entscheidend nämlich auch die Auswahl der richtigen Technik, vor allem in den Schritten 2 und 3. Aus diesem Grund möchte ich nun gerne einige der am weitesten verbreiteten Techniken in diesem Bereich vorstellen. Die meisten davon kann man nochmal ausführlich im Buch “Agile Retrospectives: Making Good Teams Great!” von Esther Derby und Diana Larsen nachlesen: mehr »