10 mögliche Gründe für's Scheitern von agilen Projekten

Bei inside-scrum findet man 10 Gründe, woran agile Projekte scheitern können.

#1 Dem Team keine Erholung lassen
#2 Kein guter 'Sponsor'
#3 Zu lange Iterationen
#4 Nicht das richtige Team
#5 Mangelnde Disziplin
#6 Spitzfindigkeiten
#7 Übertreibung
#8 Keine Schlüsselfiguren
#9 Widersprüchliche Terminologie
#10 Gerüchte

Die Ursachen im Detail zu den 10 Gründen hat inside-scrum.

jo|ce hat bei document.write(); bereits als Gast-Autor geschrieben:
Was ist Scrum?
Wie funktioniert Scrum?
Warum Scrum?

Scrum bzw. agile Software-Entwicklung in Grossprojekten

jo|ce von inside-scrum besucht in Barcelona gerade das 'TheServerSide Java Symposium'.

Und auch dort wird wohl fleissig über Scrum und agile Software-Entwicklung referiert.

Thema seines Posts vom Symposium sind Grossprojekte, mit 12 und mehr Team-Mitglieder. Und die Frage, wie agile Projekte mit einem so grossen Team überhaupt gemanaged werden können.

Es braucht dazu Feature-Teams, die Definition Done-Done, ein ausgereiftes Resourcen-Sharing, einen Kommunikations-Vermittler, eine ausgemachte und vor allem gelebte Entwicklungs-Kultur (bzw. -Vorgehen) und eine besondere Form des Reviews, die Staged Retrospective.

Für detaillierte Definitionen und wie sich das im täglichen Projekt-Geschäft anlässt, steht jo|ce auf seinem Blog sicher gerne für Fragen zur Verfügung.

10 wichtige Argumente für agile Software-Entwicklung

Bei inside-scrum gibt es die Top 10 Gründe, weshalb agile Methoden zur Software-Entwicklung (Scrum) genutzt werden sollten.

Das reicht von der Nähe zum Markt über Qualität und Transparenz bis hin zur Kostenkontrolle und dem Spass an der Arbeit.

Alle 10 Argumente für die agile Methodik und jeweils eine Erklärung findet man bei inside-scrum.

Roundup -- Softwareentwicklung mit Scrum

- Was ist Scrum?
Theorie und Historie eines gar nicht so neuen Modells

- Wie funktioniert Scrum?
Scrum braucht Regeln, Rollen und einen Arbeitstakt

- Warum Scrum?
Aussagen zur Komplexität, Zeit und Aufwand

Viel mehr zum Thema Scrum, Tools und Tipps gibt es bei inside-scrum, dem Blog von jo|ce. Vielen Dank für die wirklich lehrreichen Beiträge.

Warum Scrum?

In zwei anderen Beiträgen (Teil 1, Teil 2) in diesem Blog habe ich beschrieben, was Scrum ist und wie Scrum funktioniert. Aber warum sollte man Scrum praktizieren? Gibt es einen guten Grund?

Warum Scrum?

Wenn man zu Beginn eines Projekts eine Aussage über Komplexität, Zeit oder Aufwand machen muss, kennt man unbekanntes nicht. Das Wissen darüber wird im Verlauf des Projekts erarbeitet. Man versteht die Aufgabe erst vollumfänglich, wenn das Projekt abgeschlossen ist – jetzt sind Komplexität, Zeit und Aufwand offensichtlich. Scrum berücksichtigt dies bereits zu Beginn. Man arbeitet iterativ und kommt somit dem finalen Ergebnis schrittweise näher. Probleme und Fragen, die man morgen oder übermorgen haben könnte oder per heute noch nicht klären bzw. beantworten kann, werden bewusst vertagt. Man fokussiert auf die Dinge, die bereits zum jetzigen Zeitpunkt klar sind. Oft kennt und weiss der Kunde das Endziel selbst nicht genau. Er hat durch die iterative Arbeitsweise des Teams die Möglichkeit in regelmässigen Abständen (Sprints) neu Bedürfnisse zu Formulieren, Prioritäten zu Verschieben oder Neues zu Definieren. Er bekommt nach jedem Sprint brauchbare Funktionalität und ist nie mehr als 3 Wochen von einem einsatzfähigen Produkt entfernt. Der ROI ist durch Scrum für den Kunden maximiert - DER Grund, Scrum eine Chance zu geben...

Literatur

www.scrumalliance.org
www.mountaingoatsoftware.com/scrum/
www.controlchaos.com
www.xprogramming.com
www.allaboutagile.com
www.amazon.de/Agile-Project-Management-Microsoft-Professional
www.amazon.com/Agile-Estimating-Planning-Robert-Martin/
www.amazon.com/User-Stories-Applied-Development-Addison-Wesley
www.jeffsutherland.com/scrum/

Wie funktioniert Scrum?

Wie funktioniert Scrum?

Scrum definiert ein paar Regeln, diverse Rollen und einen bestimmten Arbeitstakt. In einem Scrum Projekt gibt es das Scrum Team, einen Scrum Master und einen Product Owner.

Scrum Team

Das Scrum Team setzt sich aus allen Kompetenzen zusammen, die man für die erfolgreiche Abwicklung einen Projekts benötigt, z.B. Datenbank und Software Engineers, sowie GUI Designer und Tester. Das Team umfasst gewöhnlich zwischen 3 und 8 Personen, je nach Art des Projekts. Es ist entscheidend, dass man ein interdisziplinäres, heterogenes Team aufstellt. Man könnte dass auch so sagen: „ … the first thing I’m going to do is get the right people on the bus, get the wrong people off of the bus and make sure everyone is in the right seat. Then, together we can decide on the best direction to drive the bus” [Jim Collins]. Es ist also für den Erfolg eines agilen Projekts nach Scrum sehr wichtig, wie sich das Team zusammensetzt.

Scrum Master

Der Scrum Master ist der Coach und Schiedsrichter. Er greift nicht in Scrum Prozesse ein. Er hält das Team von äusseren Einflüssen frei, räumt Hindernisse aus dem Weg und führt das Team zum Erfolg. Der Scrum Master sollte diverse Eigenschaften aufweisen. Es gibt genau einen Scrum Master in einem Scrum Projekt. Er wird vom Team gewählt oder von Team-ausserhalb bestimmt.

Product Owner

Der Product Owner ist quasi ein Repräsentant des Geldgebers, des Kunden. Er entscheidet, was entwickelt werden soll und in welcher Reihenfolge. Über die Rolle des Product Owners hinaus gibt es keine Einflussnahme und Mitbestimmung an einem Scrum Projekt. Der Geldgeber selbst, Vertreter des Steering Committee, Marketing etc. können Wünsche äusseren, aber nicht in das Geschehen eingreifen – nur der Product Owner gibt dem Team Arbeitsaufträge.

Wenn man sich über die Rollen und deren Befugnisse geeinigt hat kommen die Scrum Regeln ins Spiel.

Sprint Planning Meeting

Das Planning Meeting ist in zwei Teile unterteilt: Planning und Estimation, je ca. 4 Stunden. Der Kunde, vertreten durch den Product Owner stellt im Teil 1 - Planning - seine Wünsche und Prioritäten vor. Das Team hat die Möglichkeit Fragen zu stellen. Anschliessend schätzt das Team den Aufwand für die Wünsche - Estimation. Der Product Owner ist in dieser Phase nicht anwesend. Der Aufwand wird in Story Points oder Ideal Days geschätzt. Sowohl beim Planning und bei der Estimation ist das gesamte Team anwesend.

Sprint

Ein Sprint entspricht einer Iteration nach XP. Ein Sprint dauert Idealerweise zwischen 1 und 4 Wochen und repräsentiert den Arbeitstakt des Teams. Nach jedem Sprint liefert das Team brauchbare Funktionalität und bekommt dafür alle Story Points. Ziel ist es, so viel Story Points wie möglich pro Sprint zu "verdienen".

Sprint Demo

Am Ende eines Sprints werden die Funktionen präsentiert. Dabei kann der Product Owner den Entwicklungsstand selbst prüfen und gegebenenfalls für den kommenden Sprint seine Prioritäten verschieben bzw. neue Wünsche äussern. Die Sprint Demo dauert ca. 4h. Das gesamte Team ist anwesend.

Sprint Retrospecitve

Im Anschluss an den vergangenen Sprint gibt es eine 4 stündige Retrospecive, wo das gesamte Team anwesend ist und man hinterfragt was besonders gut war, bzw. wo es Optimierungspotenzial gibt. Es werden Massnahmen zur Verbesserung vom Team definiert. Der Scrum Master moderiert.

Daily Scrum

Der Daily Scrum wird vom Scrum Master moderiert. Er findet täglich statt und dauert 15 min. Es werden folgende Fragen von jedem Teammitglied beantwortet: "Was hab ich gestern gemacht", "Was mache ich heute" und "Was sind meine Hindernisse". Idealerweise sollte pro Aktivität Ziele definiert werden, die an einem Tag erreicht werden. Der Daily Scrum soll die Kommunikation und Transparenz im Team steigern - jeder weiss, woran gerade im Team gearbeitet wird. Der Scrum Master erkennt Hindernisse des Teams und nimmt sich dieser an. Bei Toyota nennt man das Obeya.

Unentschuldigtes Fehlen ist nicht erlaubt. Man kann telefonisch oder vertreten durch ein Teammitglied teilnehmen. Physische Anwesenheit ist nicht Pflicht.

Im nächsten Beitrag werde ich darüber schreiben, wann und warum man Scrum einsetzen sollte ...

Teil 1: Was ist Scrum?

Was ist Scrum?

Ich beschäftige mich schon sein einer Weile mit agiler Software Entwicklung und habe viele Erfahrungen gemacht, Erkenntnisse gesammelt, diverse Tools ausprobiert und dokumentiere dies in einem Blog. Da immer wieder gefragt wird, was Scrum sei, möchte ich die Möglichkeit eines Gast-Betrags in diesem Blog nutzen, um einen kurze Einleitung zu geben.

Was ist Scrum?

Scrum ist ein Vorgehensmodell für das Projektmanagement im Rahmen agiler Softwareentwicklung. Scrum definiert eine Sammlung von Arbeitstechniken, Strukturen, Rollen und Methoden. Das Scrum Team ist selbst-organisiertent. Scrum kann könnte für alle erdenklichen Projekte eingesetzt werden, die agile oder iterativ bewerkstelligt werden sollen, eingesetzt werden, z.B. ein Haus bauen, die Konstruktion eines Automobils, die Fussball-WM gewinnen oder auch eine Software entwickeln.

Woher kommt Scrum?

Das agile Vorgehen in Projekten kommt aus der Automobil-Industrie. Erstmals hat Toyota ein agiles Vorgehensmodell eingesetzt und man arbeitet noch heute nach diesem Prinzip. Bei Toyota wird zwar nicht Scrum praktiziert, aber Scrum hat seine Wurzeln im der Toyota Vorgehensmodell. Bei Chrysler wurde 1995 bei einem internen Pilot-Projekt erstmals Software nach agilem Prinzipien entwickelt – die Geburtsstunde von eXtreme Programming. Anders als Scrum ist XP ein reines Vorgehenmodell in der Softwaretechnik. Der Begriff Scrum kommt aus dem Rugby, bedeutet soviel wie „Den Ball im Spiel halten“ und wurde erstmals Mitte der 80iger in Produktionsumgebungen eingeführt.

In einem weiteren Gast-Beitrag werde ich beschreiben, wie und warum Scrum funktioniert. Also, dranbleiben ....