Agile Projekte mit Scrum

November 2012 (Update: Juli 2017)

Agile Projekte mit Scrum
Foto: Gert Krautbauer
 

Eine Anmerkung vorneweg

Wir haben über die Jahre eine eigene agile Kultur für die CSS entwickelt, die Elemente aus mehreren agilen Ansätzen enthält – darunter auch Scrum, den Vertreter des agilen Projektmanagements, den wir in diesem Artikel vorstellen möchten!
 

Am Anfang eine kleine Geschichte

Sie fragen sich wahrscheinlich, warum wir einen Artikel über agiles Projekt-Management mit einem Huhn und einem Schwein starten. Das hat mit einer kleinen Fabel zu tun, die in diesem Bereich immer wieder erzählt wird:

A chicken and a pig are talking.
The chicken says, "Let's start a restaurant!"
The pig asks, "What would we call this restaurant?" to which the chicken replies, "Ham n' Eggs!"
The pig thinks it over and says, "No, thank you very much: I'd be committed, but you'd only be involved!"

Was diese Geschichte auf lustige Art und Weise zeigen will, sind die zwei unterschiedlichen Ebenen an Commitment, die es in einem agilen Projekt gibt. In Scrum, einem der bekanntesten Vertreter des agilen Projektmanagements, sind das Scrum Team, der Scrum Master und der Product Owner die "Schweine" – sie tragen die Verantwortung für das Projekt

Das Management bzw. die AuftraggeberInnen sind hingegen die "Hühner": Sie sind nur am Rande beteiligt, können aber immer wieder neue Eier (also Projektaufträge) legen.

Was es genau mit dieser Rollenaufteilung auf sich hat, erklären wir später im Artikel. Machen wir zuerst einen Sprung zurück in die Vergangenheit zur Geburtsstunde des agilen Projektmanagements!
 

Die Geburtsstunde: Das agile Manifest

Im Februar 2001 trafen sich 17 Persönlichkeiten aus dem Bereich der Softwareentwicklung und des IT-Projektmanagements, um Wege zu finden "bessere Software" zu entwickeln. Das Ergebnis war das sogenannte "agile Manifest", bestehend aus vier Kernwerten und einem einzigen Ziel:

"We are uncovering better ways of developing software by doing it and helping others to do it.
Through this work we have come to value:

  • Individuals and interactions over processes and tools
  • Working software over comprehensive documentation
  • Customer collaboration over contract negotiation
  • Responding to change over following a plan

That is, while there is value in the items on the right, we value the items on the left more."
 

Die zentrale Idee

Die zentrale Idee des agilen Projektmanagements ist es, mit veränderten Anforderungen und Änderungen während der Projektumsetzung umgehen zu können. Solche Abweichungen lassen sich nie ganz vermeiden: Es ist empirisch belegt, dass sich auch bei sehr gut gemanagten IT-Projekten ca. 1,5% bis 3% der Anforderungen pro Monat der Projektlaufzeit ändern. Andere Modelle gehen davon aus, dass über die Projektlaufzeit gesehen bis zu 50% neue Anforderungen hinzukommen (sog. "Requirements Growth").

Daher ist eine logische Schlussfolgerung, dass eine Investition in professionelles Change Management wichtiger ist, als mit hohem Aufwand vor dem Projektstart zu versuchen 100% aller zu diesem Zeitpunkt bekannten Anforderungen im Detail zu spezifizieren.

Das heißt natürlich nicht, dass nichts mehr dokumentiert werden muss, wie oft fälschlicherweise angenommen wird. Die eigentliche Aussage ist, dass auch die tollste Dokumentation nicht über eine miese Software hinwegtäuschen kann!

Die klassische Planung mit klar definierten Arbeitspaketen und Projektablaufplänen wird im agilen Softwareprojektmanagement durch eine ziel-, nutzen- und funktionsorientierte Planung abgelöst.

Selbstverantwortliche, selbstorganisierte und häufig auch interdisziplinäre Teams sorgen dafür, dass alle nötigen Arbeiten zwar im Detail geplant und umgesetzt werden – aber eben erst just-in-time, wenn alle benötigten Informationen dafür vorhanden sind. Dazu wird das Projekt in fixe "Timeboxes" aufgeteilt, wo am Ende ein jeweils fertiggestellter "Value" (z.B. Features) an die AuftraggeberInnen ausgeliefert wird.
 

Wichtig: Fertig ist wirklich fertig!

Dem Begriff "fertig" kommt in der agilen Entwicklung, und speziell auch bei Scrum, eine besondere Bedeutung zu: Viele Projekte werden relativ rasch als "zu 90% fertig" bezeichnet, bleiben dann aber mehrere Monate oder Jahre lang in diesem Zustand.



Im agilen Sinne wird jeweils zu Projektbeginn definiert, was "fertig" im Kontext des aktuellen Projektes für die einzelnen Features bedeutet (wie z.B. "Funktion entwickelt und Code eingecheckt", "Blackbox-Test erfolgreich" oder "entspricht Norm XY"). Auf Basis dieser "Done List" gibt es für Features nur noch fertig oder nicht fertig umgesetzt – 99% bedeutet somit auch nicht fertig!

Agiles Projektmanagement bedeutet im Gegensatz zu vielen Vorurteilen also nicht, dass es im Projekt weniger geplant oder straff zugeht. Ganz im Gegenteil. Es werden Prinzipien konsequent eingehalten und ein inhärentes Change Management steht im Mittelpunkt der konsequenten Verfolgung des Weges durch das Projekt – vom Beginn bis zur Release der fertigen Software.


DoneList_560px.jpg
Die "Done List": Erst wenn alles abgehakt ist, ist das Feature wirklich fertig! | Foto: Sven Schweiger
 

Die Rollen in Scrum

Scrum ist der Vertreter des agilen Projektmanagements, dessen Prinzipien wir für unsere Projekte einsetzen. Der Begriff "Scrum" kommt aus dem Rugby ("Gedränge") und steht für außergewöhnlich erfolgreiche Entwicklungsteams, die als kleine, selbst-organisierte Einheiten arbeiten. Sie bekommen von außen nur eine Richtung vorgegeben, bestimmen aber selbst die Taktik, mit der sie ihr gemeinsames Ziel erreichen. (siehe dazu den Wikipedia-Artikel).

Agiles Arbeiten umfasst ein neues Rollenverständnis bezüglich Projektleitung und Management. In Scrum werden die Aufgaben der Projektleitung gleich auf mehrere Personen aufgeteilt: Scrum Master, Product Owner und das Team sowie das Management bzw. die AuftraggeberInnen. Und damit kommen wir zurück zu unseren Bauernhof-Bewohnern!
 

Die "Schweine"

Die "Schweine" sind im Scrum der Product Owner, der Scrum Master und das Team, die die Verantwortung für das Projekt trafen.

Der Product Owner vertritt während des Projekts den Auftraggeber und dessen Ziele sowie Werte im Team des Auftragnehmers.


Unsere Product Owner: Harald Deitzer, Marcel Hauer, Ralph Irschik, Sebastian Naske und Johannes Wirgler
 

Der Scrum Master ist der Coach des Scrum Teams: Er beschützt das Team gegen Einflüsse von außen, die das Team daran hindern, effizient an der Lösung der Aufgabenstellung zu arbeiten und sorgt für eine optimale agile Arbeitskultur.

Das Team trifft zahlreiche Entscheidungen selbst und trägt Verantwortung im Projekt, da es aus ExpertInnen besteht, die fachlich am besten wissen, wie die Aufgabe gelöst wird.
 

Die "Hühner"

Die „Hühner“ sind die AuftraggeberInnen bzw. das Management: Deren Rolle ist es, den ProjektumsetzerInnen (also den "Schweinen") alle Hindernisse aus dem Weg zu räumen, die eine erfolgreiche Projektumsetzung behindern.

Sie müssen Informationen rechtzeitig zur Verfügung stellen und benötigte Entscheidungen zeitnah treffen. Die "Hühner" unterliegen zusätzlich einer Hohl- und keiner Bringschuld, wenn es um Informationen zum Projektfortschritt geht.

Es liegt in ihrer Verantwortung, sich zum Beispiel in Demo-Meetings am Ende jeder "Timebox" (in Scrum: "Review Meeting" am Ende jedes "Sprints") die fertiggestellten Ergebnisse anzusehen und Feedback dazu zu geben. Die oft gehörte Ausrede "viele Auftraggeber haben keine Zeit dazu" ist ebenfalls ein gefährliches Vorurteil in Scrum: Denn wie hoch mag der Stellenwert eines Projektes für einen Kunden sein, wenn er nicht regelmäßig alle paar Wochen den Fortschritt ansehen und kommentieren möchte?

 

"Schwein" und "Huhn" – ein Rollentausch um 180°

Die Rolle des Managements ist in agil organisierten Unternehmen genauso wichtig wie in klassischen Organisationsformen. Aber die Verantwortlichkeit verschiebt sich, dreht sich am Projektbeginn quasi um: Der sogenannte "Flip" bedeutet, dass die Verantwortung für den Projekterfolg auf das agile Team übergeht und das Management in die Rolle der Beseitiger von Hindernissen und Unterstützer des Teams wechselt.

Die Aufteilung der Interessensvertretung auf den Product Owner (Kunde) und den Scrum Master (Team) ermöglicht zudem, dass Fragen, Diskussionen und Konflikte offen ausgetragen werden. Bei Projekten mit sportlichem Terminplan kann zudem leichter dafür gesorgt werden, dass es nicht zur Überlastung einer einzelnen Person – nämlich dem/der ProjektleiterIn – kommt. Agiles Arbeiten bedeutet somit eine andere Team- und Unternehmenskultur zu leben, als man es in klassischen IT-Projekten lange Zeit gewohnt war.



 

Unser Bezug zu agilem Arbeiten und zu Scrum

Als Software-Firma haben wir bereits mehrere Jahre Erfahrungen mit Scrum und agiler Softwareentwicklung gemacht und setzen diese sehr erfolgreich in Kundenprojekten ein. Wir verfügen im Team über mehrere zertifizierte Scrum Master (CSM) und Scrum Product Owner (CSPO) und unsere CEO Sven Schweiger unterrichtet agile Softwareentwicklung an der Fachhochschule Technikum Wien.

Auch wenn wir große Anhänger des agilen Projektmanagements sind, ist es für uns wichtig, dass die Art des Projektmanagements zum jeweiligen Projekt passend ausgewählt wird. Denn agiles Projektmanagement eignet sich nicht für jedes Projekt, jedes Team und jede Organisation. Es lohnt sich, mehrere Möglichkeiten in Betracht zu ziehen und bei der Auswahl des Projektmanagement-Vorgehens die alte Regel zu bedenken: "If you only have a hammer, everything looks like a nail!".
 

Mehr über unsere Art zu Arbeiten finden Sie in den folgenden Artikeln:

That’s how we roll: Die Organisation der CSS
Von der Anfrage zur Angebots­erstellung
Software Design: Gut vorbereitet ist halb fertig

Wir verfügen über mehrere Jahre Erfahrung mit Scrum und agiler Softwareentwicklung und setzen diese sehr erfolgreich in Kundenprojekten ein. Wenn Sie mehr darüber erfahren möchten, kontaktieren Sie uns!