AÜG IN DER IT-BRANCHE: NEARSHORE OUTSOURCING EINE GUTE OPTION

Mit der Verschärfung des AÜG ab April 2017 entstehen für viele Unternehmen eine Reihe von Problemen.
Und dies betrifft – anders als oft behauptet – auch die IT- und Beraterbranche. Dieser Artikel stellt dies noch
einmal unmissverständlich klar. Die Panik bei vielen Unternehmen der Branche nimmt daher ständig zu, aber
ist sie auch berechtigt?
Denn bei genauem Hinsehen bieten die Veränderungen, herbeigeführt durch das neue AÜG neben den
Problemen und Risiken auch mindestens ebenso große Chancen. Dieser Artikel beschäftigt sich damit, wie
Sie aus dem Problem AÜG eine Chance machen können, die Ihnen nicht nur viel Geld spart, sondern Ihrem
Unternehmen darüber hinaus noch einige neue Möglichkeiten eröffnet. Nearshore Outsourcing kann eine
dieser Möglichkeiten sein und eine Beleuchtung dieser Option ist Gegenstand dieses Artikels. Denn
Nearshore Outsourcing bietet das Potential, den Mangel an qualifizierten Fachkräften auszugleichen und
gleichzeitig eine Kostenreduktion herbeizuführen. Das ist soweit nicht neu. Aber nun müssen sich vor dem
Hintergrund des neuen AÜG müssen Unternehmen sich der Grundsatzfrage stellen, welche sie mit der
Langzeitbeschäftigung externer Mitarbeiter bisher umgangen sind: Mehr Mitarbeiter einstellen, oder
konsequenter outsourcen. Für letztere ist Nearshore Outsourcing mit Sicherheit die beste Alternative.
Zunächst mal wirken die Neuregelungen des AÜG auf den Betrachter deprimierend und gefährlich.
HIER EIN GANZ KURZER ÜBERBLICK ÜBER DAS NEUE AÜG:
Arbeitnehmerüberlassung geht nur noch 18 Monate. Wenn Ihr Unternehmen nicht an einen Tarifvertrag
gebunden ist, oder zumindest einen Betriebsrat hat, brauchen Sie sich über die Verlängerung dieser Frist via
Ausnahmegenehmigung gar nicht erst beschäftigen.
Die Fallschirmlösung „Vorrats AÜ-Erlaubnis“, für den Fall, dass Ihre geschlossenen Werkverträge als
Scheinwerkverträge auffliegen und Sie dann Ihre vorsorglich eingeholte AÜ-Erlaubnis zücken, funktioniert
nun auch nicht mehr.
Die Equal-Pay- und Streikbrecher- Regelungen können Sie vermutlich ignorieren, da Leiharbeiter in der IT –
mit Ausnahme von Call-Center-Agents vielleicht – in der Regel ja übertariflich bezahlt werden.
Eine recht gute und aktuelle Zusammenfassung der AÜG Materie können Sie auch in diesem Artikel
nachlesen.
WEN TRIFFT DIESES GESETZ BESONDERS HART?
1. DIE ENTLEIHER:
Große IT-Projekte laufen in der Regel deutlich länger als 18 Monate. Selbst Projekte, die auf nur 12 Monate
geplant sind, werden nicht selten im Verlauf immer größer. SCRUM Projekte unterliegen hier sicher einem
höheren Risiko als Projekte traditioneller Methodiken. Siehe dazu auch hier. . Jedenfalls kann man sich bei
der Projektplanung nicht immer zu hundert Prozent darauf verlassen, dass dies nicht passiert. Und dann sind
es oft die Key-Ressourcen, die vom externen Markt geholt werden, und mit denen man nach den 18 Monaten
nur schwer eine 3-monatige Pause vereinbaren kann, sowohl aus Projektsicht, als auch aus Sicht der Key-
Ressource.
2. DIE VERLEIHER
Es gibt unzählige kleine und mittlere IT-System- oder Beratungsunternehmen, die oft selbst zu klein sind, um
größere Projekte zu gewinnen und oft Ihre wertvollen Mitarbeiter in Langzeitprojekte bei Kunden „versenken“.
Das garantiert regelmäßiges Einkommen und eine gewisse – wenn auch manchmal trügerische – Sicherheit.
Alle, die dieses Modell seit Jahren fahren, wissen, wovon ich spreche. Auf die großen Recruiter, die das
sicher auch trifft, möchte ich hier nicht weiter eingehen. Und natürlich trifft es auch die inzwischen auch recht
zahlreich vertretenen Konzerntöchter und die Töchter der Töchter usw. Siehe dazu auch diesen Artikel.
Damit haben wir hier die Konstellation, die bei genauerem Überlegen gar nicht mal so häufig ist, dass das
gleiche Problem gleichermaßen auf der Anbieter (Verleiher)- wie auf der Nachfrager (Entleiher)- Seite
existiert. Und selbst die Arbeitnehmer gehören zu den Verlierern. Zumindest in der IT-Branche, denn das
Gesetz ist eigentlich für ganz andere Branchen entworfen. Die IT trifft es nur auch. Der Gesetzgeber verbietet
diese friedliche Koexistenz, die all die Jahre so wunderbar funktioniert hat und zwar für alle. Das ist schon
ein Novum, dennoch eine Realität und jammern hilft nichts.
Nun könnten sich ja alle beruhigt zurücklehnen und denken, wenn es alle gleichermaßen trifft, dann werden
sich alle auch schnell einig werden über eine Lösung. Aber so funktioniert der Markt nun mal leider nicht.
Nach dem ungläubigen Staunen über diese Torheit des Gesetzgebers bricht – heute schon spürbar – bei
vielen eine gewisse Panik aus. Denn es passiert zu einer Zeit, in der IT-Fachkräfte ohnehin „Mangelware“
sind. Alle, die gerade auf der Suche nach einem SAP-Berater, Scrum-Coach oder SharePoint Entwickler
sind, wissen was ich meine. Was wird also die Zukunft nach dem 1.4.2017 bringen? Kleine Unternehmen
stellen sich die Frage, werfe ich jetzt 2 Leute raus, da ich nicht weiß, ob mein Kunde, die in seinem
Langzeitprojekt noch beschäftigen darf oder stelle ich 3 Leute ein, weil eigentlich genug Arbeit da ist und die
großen nun ganze Projekte rausgeben?
WIE WÜRDEN SIE ENTSCHEIDEN?
Für die einen wird es so laufen, für die anderen anders. Wie immer im Leben und wie immer bei so
grundsätzlichen Veränderungen, die auf einmal alle treffen. Je besser Sie vorbereitet sind, desto größer sind
Ihre Chancen. Das waren jetzt zwei ordentlich Phrasen, aber sie sind leider wahr.
Die Überschrift des Artikels behauptet, dass Nearshore outsourcing eine Lösung des Problems für viele sein
kann, die dabei nicht nur Lösung ist, sondern gleichzeitig zusätzliche Möglichkeiten eröffnet. Mag sein, dass
ein findiger Beamter bei der Überarbeitung des Gesetzentwurfes oder auch bei der Durchsicht der vielen
Petitionen aus der IT-Branche verwundert den Kopf geschüttelt hat und sich dachte: „Wo ist deren Problem?“
Gerade in der IT-Branche sind wir auf die Eingliederung der entliehenen Mitarbeiter in den Betrieb des
Entleihers gar nicht angewiesen. Schlimm genug, dass remote-Arbeit hier nicht längst zum Standard gehört,
denn es braucht doch kaum mehr, als ein Laptop, vernünftige Kommunikationsmöglichkeiten und natürlich
eine entsprechende Methodik. Tausende Unternehmen in hunderttausenden Projekten über alle Branchen
und Projekttypen hinweg arbeiten so seit Jahren. Und das nicht weniger erfolgreich, als in ihren Onsite-
Pendants.
Die Gründe, warum dies in Unternehmen bisher oft nicht in Betracht gezogen wird sind mindestens dreierlei.
Und vergessen sie nicht, ich spreche hier nur von Unternehmen und deren Projekten, die regelmäßig aus
guten Gründen mit externen Mitarbeitern gestafft werden und nicht von denen, die aus ebenfalls vielen guten
Gründen mit festangestellten Mitarbeitern arbeiten:
Unternehmen sind methodisch oft nicht trainiert, ihre Projekte so zu steuern, dass der Ort der
Leistungserbringung der externen Mitarbeiter – sei es auch in gemischten Teams aus internen- und externen
Mitarbeitern – egal wird. Das Misstrauen gegenüber solchen Mischformen ist groß. Und es ist auch real –
darüber muss man gar nicht diskutieren – solange die Methodik das nicht ermöglicht.
Diese methodische Unzulänglichkeit schließt übrigens auch ein, dass viele Projektleiter sich nicht in der Lage
sehen, aus einem sehr großen Projekt mehrere kleinere Teilprojekt zu machen, die als Teilleistungen separat
erstellt werden können. In der Realität ist dies aber meist der Fall und wird selbst bei großen internen Projekt-
Teams so gehandhabt.
Und schließlich ist der Druck über so etwas nachzudenken und daraus resultierende vermeintliche Risiken
einzugehen schlicht nicht groß genug. Manche IT-Abteilungsleiter definieren sich auch noch immer über die
Größe der sichtbaren Mannschaft, der ganzen Etage, die sie befehligen. Auch das beobachte ich in der
Praxis noch häufig. Mindestens an dieser Stelle wird noch sehr viel Geld in Unternehmen verbrannt.
Die Neuregelung des Gesetzes sagt nun, dass Unternehmen in der oben beschriebenen Situation nun zwei
Möglichkeiten haben. Entweder sie stellen die Langzeitprojektler, die manchmal viele Jahre in Abteilungen
leben bei sich in Festanstellung an oder sie gewöhnen sich einen Arbeitsstil an, der es Ihnen ermöglicht,
Arbeit rauszugeben, sei es als Werkvertrag oder als Dienstleistungsertrag. Ersteres scheitert oft daran, dass
die Langzeitprojektler sich in dieser langen Zeit an die übertarifliche Bezahlung und den Lebensstil gewöhnt
haben. Man ist also hier darauf angewiesen, dass sie es auch wollen, was in vielen Fällen mindestens
bezweifelt werden darf.
Also bleibt als zumindest als sicherer Weg die zweite Alternative. Dabei profizieren die Unternehmen von
zweierlei:
Erstens sind diesen Weg erfolgreich schon tausende Unternehmen weltweit vor ihnen gegangen, sodass die
erforderlichen Techniken und Methodiken längst ausgereift sind
Zweitens gibt es genügend Unternehmen mit ausreichend Kapazitäten und Erfahrungen, diesen
Outsourcing-Weg schnell zu ermöglichen.
Und hier kommt Nearshore Outsourcing ins Spiel. Nearshore Outsourcing, insbesondere deutschsprachiges
Nearshore Outsourcing kann Ihnen nicht nur helfen, das AÜG Problem zu lösen, sondern gleichzeitig
verschaffen Sie sich dadurch eine bessere Ressourcen-Flexibilität und natürlich eine nicht unwesentliche
Kostenreduktion.
Die Formel hier lautet: Wenn Sie sich wegen der AÜG Problematik ohnehin neu
orientieren müssen und eine Option dabei das Rausgeben der Arbeit, statt des
Einholens von Leiharbeitern ist, dann machen Sie es gleich richtig und sparen dabei
langfristig auch noch viel Geld und lösen das Problem mit knappen Ressourcen gleich
mit.
Im Nearshore Outsourcing stehen Ihnen dabei grundsätzlich zwei Möglichkeiten offen:
Client Owned Nearshore: Den Aufbau von ganzen Teams, die Ihnen „gehören“, also das Verlagern von
ganzen IT-Abteilungen dorthin, wo es günstig ist und wo ausreichend IT-Fachkräfte, sogar mit deutscher
Sprache zur Verfügung stehen.
Projektoutsourcing: Das Mieten eines Nearshore Teams für ein bestimmtes Projekt im Rahmen eines Werk-
oder Dienstleistungsvertrages.
Welche Möglichkeit die Beste ist, hängt von Ihren Anforderungen und Zielen ab. In jedem Fall ist es für alle
AÜG – geplagten eine interessante- und vor allem eine schnelle Alternative. Blubito – Nearshore war noch
nie so nah

............................................................................................................................................................

FIT FOR SCRUM – WIE TRAINIERE ICH EIN TEAM IN SCRUM?

SCRUM ist nun schon deutlich über 10 Jahre alt und erfreut sich wachsender Beliebtheit, zumindest in der
öffentlichen Diskussion. So verwundert es, dass in den meisten Unternehmen, die neue Projekte beginnen,
SCRUM immer wieder neu eingeführt werden muss, weil weder Teams noch Projektleitung darin sehr geübt
sind. Somit beginnt jedes Projekt zunächst damit, das Team und den Product Owner, vielleicht sogar die
ganze Projektorganisation in der das Projekt eingebettet ist, fit für die Methodik zu machen. Da SCRUM als
Implementierungsmethodik ohnehin ein Kompromiss ist, mit einer nicht perfekten Welt umzugehen, ist die
Unkenntnis der Methodik eine weitere schwere Hypothek und Grund für das Scheitern vieler Projekte. In
einer solchen Situation stehen SCRUM Coaches, SCRUM Master und agile Projektmanager vor der
Herausforderung, die Teams und Stakeholder möglichst schnell fit für den effektiven Einsatz von SCRUM zu
machen. Dabei wird es von entscheidender Bedeutung sein, die richtigen Akzente zu setzen und
Kompromisse an genau der richtigen Stelle zu machen. In diesem Beitrag möchte ich einen Ansatz
vorstellen, der in meiner Praxis gut funktioniert hat und nach sehr wenigen Sprints stets signifikante
Verbesserungen zeigt.
Selten war der Spruch ‚Hast Du es eilig, geh langsam‘, so passend wie in dieser Situation

Nämlich der Herausforderung ein Team in einem bereits laufenden Projekt – egal ob das Projekt gerade erst
begonnen hat, oder der erste SCRUM-Einführungsversuch gescheitert ist – schnell und gleichzeitig
nachhaltig einzuführen. Die Voraussetzung für die schnelle und erfolgreiche Einführung von SCRUM ist
Geduld, wir werden etwas weiter unten darauf zurückkommen. Der hier beschriebene Ansatz funktioniert
insbesondere deshalb so gut, weil die Probleme in vorher gescheiterten SCRUM-Einführungen oder in
neuen, unerfahrenen Teams fast immer die gleichen sind. Dies wiederum liegt darin, dass ein SCRUM-
Master Zertifikat in zwei Tagen ‚geschossen‘ werden kann, oder anders ausgedrückt, es liegt oft daran, dass
SCRUM wenig komplex ist, mit wenigen Rollen auskommt, nur wenige Prozesse kennt, überschaubare
Artefakte definiert und auf sehr wenigen Paradigmen beruht. SCRUM sieht auf den ersten Blick verführerisch
einfach aus, was in der Praxis oft dazu führt, dass SCRUM – sagen wir mal – sehr mechanisch eingeführt
wird. Es wird übersehen, wie perfekt diese wenigen Dinge ineinandergreifen müssen, damit ein sehr
effektiver Prozess in Gang kommt. Oder anders ausgedrückt, es gehört schon viel Genie dazu ein Kunstwerk
mit nur einem Pinsel und zwei Farben zu erstellen. Und wenn es gelungen ist, dann sieht es für den
Betrachter absolut simpel aus, und doch wird er es nie nachmachen können. Fragen Sie mal bei Picasso
nach. Der zweite Grund, warum dieser Ansatz fast immer funktioniert liegt darin, dass dieser Ansatz quasi
die Reset-Taste drückt und SCRUM unabhängig und voraussetzungslos neu einführt. Auch dies ist nur
möglich, weil SCRUM in der Tat eigentlich wenig komplex ist, man muss es nur richtigmachen, dann kann
es schnell gehen. Leicht ist es allerdings nicht.
WISSEN, WORAUF ES ANKOMMT: DIE RICHTIGEN KOMPROMISSE MACHEN

Wenn in einem schwierigen Umfeld etwas schnell erledigt werden soll, dann ist klar, dass gewisse
Kompromisse gemacht werden müssen. Ein Kompromiss ist nicht per Definition gut oder schlecht.
Kompromisse machen ist nie sehr effizient, Kompromisse sind in der Regel auf die Erreichung eines
bestimmten Zieles gerichtet, sie stehen also mehr auf der Seite der Effektivität, übrigens genauso wie
SCRUM als ein Kompromiss den Fokus von EFFIZIENTER SOFTWAREENTWICKLUNG AUF EFFEKTIVE
SOFTWAREENTWICKLUNg verschiebt. Ich muss sicher nicht ausführen was passiert, wenn Sie in der Eile
die falschen Kompromisse machen, es passiert genau das, was immer passiert, wenn in der Eile falsche
Kompromisse gemacht werden, dafür wurde das schöne Wort ‚Verschlimmbessern‘ so wunderbar treffend
erfunden. Die Frage ist, wie finden Sie heraus, welche Kompromisse für die Erreichung Ihres Zieles gut sind
und welche es nicht sind, denn Kompromisse werden Sie machen müssen. Diese Frage lässt sich
glücklicherweise eindeutig beantworten: SCRUM beruht im Wesen auf nur zwei Grundprinzipien, auf
COMMITMENT UND COMPLETION. Da SCRUM im Kern auf nur diesen beiden Paradigmen beruht – es
hätten durchaus mehr sein können, wie Qualität, Verlocity oder Teamarbeit – sollte jedem einleuchten, dass
keines von beiden wirklich verhandelbar ist, also für einen Kompromiss taugt. Machen Sie bei einem der
beiden Kompromisse, dann kompromittieren Sie schon 50% der gesamten Basis Ihrer Methodik. Das kann
nicht gut sein. Wenn Sie sich also überlegen, welche Kompromisse Sie machen dürfen und welche Sie auf
gar keinen Fall machen können, dann stellen Sie sich folgende Frage:
Bleibt mein Team bei dem was ich jetzt ändern möchte noch Commitment- und Completion-fähig?

Wenn Sie diese Frage nicht mit einem klaren ‚ja‘ beantworten können, dann ist das was Sie gerade vorhaben
definitiv kein guter Kompromiss. Alles, was die Commitment- oder Completionfähigkeit eines Teams in Gänze
oder in einem Sprint negativ beeinflusst, sollte unterlassen werden. Alles andere können Sie weiter in
Erwägung ziehen.
FERTIG WERDEN ÜBEN

Das erste was ich mit Teams trainiere ist fertigwerden. Dies leitet sich unmittelbar aus dem vorher über das
Wesen von SCRUM Gesagten ab. Nehmen Sie es mir nicht übel: Softwareentwickler haben ungefähr
genauso viele Definitionen des Begriffs ‚fertig‘, wie Eskimos vom Begriff ‚Schnee‘. Und ich kenne sie alle: ‚ich
bin fertig, habe aber noch nicht getestet‘, ‚ich bin fast fertig‘, ‚gestern hat es noch funktioniert‘, ‚ich bin fertig,
wir müssen da später aber vielleicht noch mal ran‘, ‚eigentlich bin ich fertig‘, die Liste könnte ich noch eine
gute Stunde fortsetzen, der Kreativität der Entwickler scheint da kaum eine Grenze gesetzt zu sein. Wenn
SCRUM aber nun auf nur zwei Paradigmen beruht und eine davon ‚Completion‘ ist, dann ist natürlich klar,
dass es wesentlich darauf ankommt, eine klare Definition des Begriffs ‚fertig‘ zu finden und diesen Prozess
des Fertigwerdens überhaupt erst einmal einzuüben. Der Begriff ‚fertig‘, der in SCRUM zu Anwendung
kommt, leitet sich aus der ‚Definition of Done‘ ab und ist nicht verhandelbar. Mein Golflehrer sagte mir zu
Beginn meiner Karriere: ‚Das Wesen des Golfspiels beruht darauf, den Ball in die Luft zu bekommen. Dass
er auch weit und in die richtige Richtung fliegt ist am Anfang ganz sekundär, das kommt später von ganz
alleine‘. Und so war es dann auch.
Wenn Sie Ihr Team erstmal dazu kriegen, eine Story abzuschließen, dann haben Sie schon die halbe Miete
eingefahren. Im ersten Sprint sage ich dem Team immer, es ist völlig egal, wie lange es für die
Implementierung einer Story braucht, mir ist völlig egal, ob sie vier, zwei oder nur eine Story im Sprint
schaffen. Verlocity ist kein Thema, Verlocity ist der erste große Kompromiss den ich eingehe, um das Lernziel
‚Completion‘ zu erreichen. Ja, ich motiviere die (erstaunten) Teams geradezu die einzelnen Tasks möglichst
pessimistisch und richtig satt zu schätzen. So satt, dass sie in jedem Fall mit der Story fertig werden und
wenn es nur eine kleine Story ist. Sie sollen sich daran gewöhnen, ein Commitment so zu geben, dass sie
es unter allen Umständen auch halten können. Hier müssen Sie als SCRUM Coach oder Projektleiter Geduld
haben. Wenn ein Team sich an das Fertigwerden gewöhnt hat, kommt die Verlocity von ganz alleine. Wenn
Sie es konsequent machen, dann dauert das nicht länger als 2 bis 3 Sprints. Ich weiß, zwei Sprints können
sehr teuer sein und es fällt schwer zwei Sprints diese Geduld aufzubringen, man muss sich da schon richtig
auf die Lippen beißen. Aber bedenken Sie, SCRUM sieht nur auf den ersten Blick so einfach aus, in der Tat
ist es das nicht und mit zwei Sprints sind sie gar nicht mal schlecht bedient.
Das Fertigwerden-üben beinhaltet insbesondere den Prozess, des Erstellens eines Commitments, welches
im Sprint-Planning 2 durch das Schätzen der technischen Subtasks für eine Story geschieht.
Softwareentwickler schätzen in der Regel immer zu optimistisch. Das hat wesentlich drei Gründe: Beim
Schätzen einer Story werden immer wieder eine Reihe von Tasks vergessen, es wird im Wesentlichen nur
die Implementierung geschätzt und solche Tasks wie Unit-Tests, Code-Dokumentation, Code-Review,
Continuous-Integration, Code-Refactoring, Präsentation vorbereiten, Know-how Transfer, Workshops,
Kaffee trinken, in Facebook mit Freunden chatten werden regelmäßig schlicht vergessen. Dann sind
Entwickler jeder für sich ja auch Superhelden, und nach dem Motto ‚wer bremst, verliert‘ will jeder mit seiner
Schätzung nicht wie der Loser dastehen. Und schließlich schätzen Entwickler immer den Happy-Path, sie
gehen immer davon aus, dass immer alles glatt läuft und sie sofort nach dem Planning und bis zum Review
ohne Unterbrechung und ohne Störung ihren Code schreiben können und immer alles sofort perfekt ist. Es
ist die Stunde des SCRUM – Masters, der darauf achten muss, dass für eine Story ausreichend Subtasks
für alle oben genannten Dinge erstellt werden, dass ausreichend Puffer einkalkuliert wird und fair geschätzt
wird. Da kann plötzlich eine simple Story, die nur ein User-Profil in einem Fenster anzeigen soll, schon schnell
mal 4 Tage dauern. SCRUM verlangsamt nicht die Entwicklung, SCRUM ist wie ein Karies-Test – ‚oh alles
rot‘ – SCRUM macht den Prozess transparent und gibt Ihnen später die Möglichkeit gezielt an der Velocity
zu arbeiten. Um sich das nutzbar zu machen, achten Sie von Anfang an darauf, dass einzelne Subtasks für
einzelne Entwickler nie länger als 8 Stunden dauern dürfen, vergessen Sie nicht, dass ein zweistündiger
Workshop mit 3 Teilnehmern nicht 2 sondern 6 Stunden Aufwand bedeuten und das eine Story auf keinen
Fall länger als ein Sprint dauern darf.
KOMMUNIKATION VERÄNDERN

Um den Prozess des Fertigwerdens zu unterstützen und dann auch zügig einen Übergang zu finden, um die
Velocity zu erhöhen ist es im nächsten Schritt erforderlich an der Kommunikation zu arbeiten. Es geht hier
weniger darum wie kommuniziert wird, sondern mehr darum was kommuniziert wird bzw. worauf sich die
Kommunikaiton bezieht. Nehmen wir als bestes und einfachstes Beispiel das Daily Standup. Viele Scrum-
Master gehen hier sehr mechanisch vor und fragen die drei Fragen nach Lehrbuch: ‚Was hast Du gestern
gemacht?‘, ‚Was planst Du heute zu tun?‘ und ‚Was hat Dich daran gehindert, Deine gestrige Aufgabe zu
erledigen?‘. Das mag zwar sehr kommunikativ erscheinen, denn man unterhält sich ja über die Arbeit im
aktuellen Sprint, geht aber am Kern des Meetings oft ziemlich vorbei. Auch hier nehmen wir ernst, worauf
SCRUM tatsächlich beruht, auf Commitment und Completion. Und genau diese gilt es, im Daily Standup zu
überprüfen. Das einzige, was mich als Scrum Master im Daily wirklich interessiert ist die Frage, ob das
Commitment noch gilt. Und diese Frage würde ich den Team Mitgliedern daher auch genau so stellen: ‚Gilt
Dein Commitment für diesen Sprint heute noch?‘. Denn erstens kann diese Frage mit einem klaren Ja oder
klaren Nein beantwortet werden. Bei einem ‚ja‘ ist das Meeting dann auch sehr kurz, nämlich unmittelbar
zuende. Bei einem ‚nein‘, geht die Diskussion sofort in Richtung Completion. Neben der Aufnahme der
Impediments gilt nun sofort zu klären welche der Stories denn noch die Chance haben, fertiggestellt zu
werden. Zweitens wird dem Team immer wieder klar der Bezug zum Wesen der Methodik vermittelt. Das
sollte so lange und so penetrant eingeübt werden, bis das Besinnen auf Commitment und Completion so
selbstverständlich sind wie das morgentliche und abendliche Zähneputzen. Auch das ist uns ja mal vor langer
Zeit durch permanentes, tägliches und vor allem kompromissloses Wiederholen erfolgreich vermittelt
worden.
Der zweite Aspekt der Kommunikation, der ebenfalls gleich am Anfang eingeführt werden muss ist die
Perspektive der Kommunikation. SCRUM Projekte scheitern oft daran, dass Teams auf Biegen und Brechen
ihre gewohnte wasserfallartige, technische Perspektive in den Scrum-Prozess pressen möchten. SCRUM
führt eine radikal vertikale, feature-orientierte Softwareentwicklung ein, während das gewohnte Wasserfall
auf eine horizontale, layer-orientierte Entwicklung setzt. Den Teams muss gleich am Anfang
unmissverständlich klargemacht werden, was das bedeutet. Die meisten Teams sehen die Methodik
überhaupt nicht unter diesem Aspekt, sie denken, dass lediglich Ihre Arbeit etwas anders organisiert ist, aber
das sonst alles beim Alten bleibt, sie also wie gewohnt schön damit beginnen ein Datenmodell zu erstellen
und sich Gedanken über einen Data-Access-, einen Business-Logik- und Repräsentations-Layer machen,
statt für die erste Funktion einen kleinen Prototyp durch alle Schichten hindurch zu entwerfen. Folgerichtig
hören wir dann auch immer wieder die Argumente von Entwicklern, dass sie ohne Architekturmodell gar
keinen Prototypen bauen können oder ohne ausgereiftes Datenmodell später alles refactored werden muss.
SCRUM führt eine feature-orientierte Perspektive ein, der Product Owner beschreibt die Stories aus rein
funktionaler Perspektive, es gibt keine technischen Stories, die Sprache im Planning 1 ist rein funktional und
repräsentiert ausschließlich die Anwenderperspektive. Je früher Sie Ihr Team dazu bekommen im Planning
1 die Dinge aus der Perspektive des Product Owners zu sehen, desto eher sind sie in der Lage, neben den
Anforderungen der Stories auch die Vision des Produktes zu verstehen, und basierend darauf schon sehr
früh wesentliche Technologie- und Architekturentscheidungen zu treffen. Erreichen tun sie das, indem alle
technischen Diskussionen aus dem Planning 1 verbannt werden und nur über die funktionale Anforderung
gesprochen wird, bis die Gehirne der Entwickler mit dem des Product Owners gleichgeschaltet sind. So
funktional die Sprache im Planning 1 ist, so technisch wird sie dann im Planning 2, denn hier geht es nur
noch darum, für die gerade diskutierte fachliche Anforderung einen – so konkret und detailliert wie irgend
möglich – technischen Implementierungsplan zu erstellen. Die darin kreierten Subtasks dürfen sich nur noch
mit dem technischen ‚wie‘ befassen. Die meisten Sprint-Backlogs sind auf Story-Ebene zu wenig fachlich
bzw. schon zu technisch (bis hin zu reinen technischen Stories) und gleichzeitg auf Subtask-Ebene viel zu
wenig technisch, beschreiben also immer noch das ‚was‘ aber nicht das ‚wie‘ (z.B. Funktion implementieren,
Funktion testen, Funktion dokumentieren, etc. statt Class xy um Methode z mit folgenden Properties
erweitern).
RETROSPEKTIVE NUTZEN

Alles oben Gesagte setzt einen Prozess des Besserwerdens in Gang.

Als Maß für das Besserwerden können und sollten Sie die Velocity in Form von Storypoints verwenden.

Auch wenn wir oben in den ersten Schritten beim fertigwerden Lernen den Fokus auf Commitment und
Completion gelegt haben und die Velocity explizit als Fokus abgewählt haben, so bleibt sie doch das Maß
der Lernkurve. Die Velocity stellt sich von allein ein, wenn die Voraussetzungen erfolgreich geschaffen
wurden. Um das zu erreichen fehlt nun noch ein letzter Schritt. Um erfolgreich besser zu werden, sollte der
Prozess des Besserwerdens institutionalisiert werden, Sie brauchen ein explizites Forum, in dem Sie sich
mit dem Besserwerden beschäftigen können, wo das und nur das Thema ist und nicht irgendwo nebenbei
behandelt wird. Dieses Forum ist die in der Praxis völlig unterschätzte Sprint-Retrospektive. In einem
Wasserfallprozess durchlaufen Sie den Softwareentwicklungszyklus aus Spezifikation, Implementierung,
Test, Dokumentation, Rollout nur einmal. Eine Lessons-Learned am Ende des Projektes (sehr beliebt beim
Management) macht strenggenommen gar keinen Sinn, denn das nächste Projekt könnte völlig anders sein,
anderer Gegenstand, anderes Team, andere Umgebung, etc. In SCRUM durchlaufen Sie den gesamten
Prozess in jedem Sprint und es gibt viele Sprints, also viele Gelegenheiten im aktuellen Projekt Dinge zu
verbessern.
Die Sprint-Retrospektive ist die institutionalisierte Instanz für die Erzeugung einer Lernkurve.
Der einzige Ort, wo sie das wichtigste in SCRUM managen können, nämlich die Frage, wie können wir
unseren Prozess optimieren und schließlich die Velocity steigern. Neben allen Hinweisen, was andere besser
machen sollten, also Projektleiter, Product Owner, der Papst oder sonst wer, sollte der Scrum Master darauf
achten, dass das Team pro Sprint in der Retrospektive mindestens eine Sache identifiziert, die das Team
selbst besser machen möchte. Im Folgesprint sollte diese eine Sache dann auch bewusst angegangen
werden, quasi als Sprintziel mit aufgenommen werden und am Ende genauso gereviewed werden wie die
Stories. Nur so bekommen sie auch hier einen Routineprozess in Gang dessen Erfolge nicht lange auf sich
warten lassen werden.
............................................................................................................................................................

DIE STORY IN SCRUM UND WARUM SICH DIE MÜHE LOHNT

AM ANFANG STEHT DAS WORT – IN SCRUM ALS STORY

Softwareentwickler schreiben nicht gerne Texte. Dies gehört zu einer der universellsten Tatsachen seit
Erfindung der Softwareentwicklung. Übrigens lesen sie auch nicht gerne Text, jedenfalls nicht wenn es sich
um technische Dokumentationen oder Spezifikationen handelt, die für ihr Projekt wichtig oder relevant wären.
Oft gilt das auch für die Story. Letzteres ist insofern auch nicht weiter verwunderlich, da diese Texte wiederum
von Entwicklern geschrieben wurden, die, wie oben erwähnt gar nicht gerne Texte schreiben, was sich
natürlich unmittelbar auf die Qualität der Texte auswirkt. Ein Teufelskreis. Man könnte meinen, SCRUM ist
entweder von solchen frustrierten Entwicklern erfunden worden, oder von Projektleitern, die Mitleid mit
Entwicklern hatten, oder es ihrerseits schlicht aufgegeben haben, Dokumentationen einzufordern, ohne
realistische Aussicht diese jemals in angemessener Qualität zu bekommen. Passend dazu dürfte das Prinzip
‚working software over comprehensive documentation‘ aus dem ‚MANIFESTO FOR AGILE SOFTWARE
DEVELOPMENT‘, zumindest in meiner professionellen Praxis der wohl von Software Entwicklern meist
zitierte Satz sein.
Auch wenn die oben genannten Akteure in gewisser Weise sogar recht haben, wirkt sich unglücklicherweise
die Mentalität viel zu oft auch auf das Schreiben von Stories aus. Und das hat dann fatale Folgen.

Schlecht- aber vor allem unvollständig geschriebene Stories sind eines der häufigsten
Gründe für das Scheitern von SCRUM Projekten.
Zum Teil verantwortlich dafür ist wiederum oft die Missinterpretation eines weiteren Prinzips aus dem
Manifesto: ‚Individuals and itneractions over processes and tools‘ bzw. ‚The most efficient and effective
method of conveying information to and within a development team is face-to-face conversation ‘. Beides
klingt auf dem ersten Blick nicht gerade nach guten Argumenten für ein Plädoyer für gut geschriebene
Stories. Allerdings und wie wir später noch sehen werden, muss erstens eine gut geschriebene Story nicht
unbedingt sehr lang sein, und zweitens basieren die beiden oben genannten Prinzipien auf gut
geschriebenen Stories und beschreiben, wie der Prozess im Anschluss daran aussehen soll. Und da gibt es
dann noch einiges zu klären, angefangen bei Architektur-Entscheidungen über Implementierungs-Plan, CI-
Strategie, Test-Plan, Deployment-Strategie, Know-how-Transfer, usw. Alles Angelegenheiten, in denen
direkte Kommunikation der beteiligten Akteure absolut unablässig ist und wesentliche Vorteile der SCRUM
Methode zum Vorschein bringt.

Die Story, als geschriebenes Artefakt bildet für diese Kommunikation die Grundlage und
den verlässlichen Bezugspunkt und genau darum erfordert sie besonderes Augenmerk.

Nochmal, nahezu alle Prozesse und Entscheidungen, die in einem SCRUM Projekt stattfinden (Prozesse)
bzw. getroffen (Entscheidungen) werden beziehen sich auf die ihnen zugrunde liegenden Stories, denn um
gute Software entwickeln zu können, braucht es eigentlich nicht viel mehr (um sie warten und betreiben zu
können, braucht es allerdings dann später doch noch etwas mehr). Über den Stellenwert einer Story im
SCRUM Prozess ist jetzt genug gesagt worden. Nun kümmern wir uns um die Frage, wie denn eine gute
Story geschrieben werden sollte.

JETZT GEHT’S LOS… ODER NOCH NICHT?

Eine Story ist Teil eines Product-Backlogs, welches die Gesamtheit der für das Software Projekt relevanten
funktionalen Anforderungen abbildet. In großen Entwicklungsprojekten empfiehlt es sich eine zweistufige
Hierarchie mit Epics und Stories einzuführen. Epics repräsentieren darin allgemein gesprochen ganze
Software-Module bzw. aus funktionaler Sicht übergeordnete Geschäftsprozess Gruppen (z.B. innerhalb
eines ERP Systems das Bestellwesen, das Rechnungswesen, das CRM oder die Lagerhaltung) während sie
Stories die einzelnen funktionalen Anforderungen repräsentieren. In kleineren Projekten wie zum Beispiel
einem Webshop kann auf die Epic-Ebene verzichtet werden. Auf die Stories kann niemals verzichtet werden.
Ich gehe hier darauf ein, wie eine gute Story geschrieben werden sollte. Für Epics gilt im Wesentlichen das
gleiche und alles was wir hier über die Story sagen, kann leicht auf die Epics übertragen werden, die
Gewichtungen können dabei leicht variieren.
Eine Story wird in der Regel vom Product Owner (PO) geschrieben, mindestens aber trägt er für die Story
die alleinige Verantwortung und diese ist nicht delegierbar. Der PO darf sich beim Schreiben der Story
selbstverständlich jedweder Hilfe bedienen. Bevor ein PO mit dem Schreiben einer Story beginnt sollte er
aber mindestens folgende Überlegungen anstellen:
1. Eine Story sollte aus rein funktionaler Perspektive geschrieben werden. Es wird ausschließlich das ‚was‘
beschrieben, nicht das ‚wie‘. Das ‚wie‘ obliegt später dem Entwicklerteam in all den oben genannten
Folgeprozessen, für die dann face-to-face Kommunikation so wichtig wird.

2. Die Story soll später von Menschen (Entwicklern) gelesen und verstanden werden und – ganz wichtig –
im Idealfall soll es neben der Story nichts weiter an Text geben müssen. Die Story muss also die funktionale
Anforderung vollständig und zielgruppengerecht beschreiben.

3. Zum Zeitpunkt des Lesens (Sprintplanning) werden in der Regel noch nicht alle Stories für das
Gesamtprojekt vorliegen, die Story muss es also irgendwie schaffen, die Vision für das Gesamtprodukt
erkennbar zu machen, damit wesentliche Architekturentscheidungen schon zu diesem frühen Zeitpunkt
getroffen werden können.

4. Die Entwickler haben es ohnehin schon schwer genug; sie müssen bekommen die Software nur
scheibchenweise beschrieben und sollen aber in jedem Sprint idealerweise funktionsfähige Software
abliefern. Die Stories müssen diesen Prozess unterstützen und nicht verhindern. Sie sind nicht einfach nur
Requirements, sie sind Teil des gesamten Prozesses und der Story muss das Bemühen anzusehen sein,
dass der PO diesen Prozess unbedingt unterstützen möchte. Das klingt zwar etwas „schwammig“ aber den
meisten Stories sieht man dieses Bemühen nicht an. Lesen Sie mal bei Kants Kritik der reinen Vernunft nach.
Das Thema ist nicht trivial, aber Sie lesen in jeder Zeile das unermüdliche Bemühen des Herrn Kant, den
Leser wirklich bei der Hand zu nehmen und ihm das ganze Verständlich zu machen. Ein Wesenszug, den
sich Herr Hegel schon nicht mehr wirklich zu Eigen gemacht hat. Da wird die Welt schon ziemlich von oben
herab beschrieben (wenn auch im Kern nicht weniger geistreich).

5. Erster Meilenstein bei der Verarbeitung einer Story ist im Sprint Planning II das Abgeben eines
Commitments in Form einer Schätzung. Die Story muss also bewertbar sein. Außerdem wäre es
zweckmäßig, die Möglichkeit zu eröffnen, später auch die Velocity des Teams zu messen. Damit wird sie
tatsächlich Teil des Ganzen Prozesses und bildet nicht nur einfach die funktionale Anforderung ab. Um das
zu erreichen, sollte jede Story einen- und nur einen funktionalen Elementarprozess abbilden. Dieser ist durch
folgende Eigenschaften gekennzeichnet:
a) Ein Elementarprozess ist ein in sich geschlossener Geschäftsprozess und sollte nicht weiter zerlegbar
sein (z.B. die Änderung einer Adresse in einem Bestellprozess, das Checkin auf einer Airline-Website).
b) Der Elementarprozess sollte funktionale end-2-end testbar sein.
Die Beschreibung solcher Elementarprozesse im Rahmen der Stories gibt Ihnen die Möglichkeit bei der
Schätzung leicht jede Metrik wie Story-Points, Function-Points oder Zeit anzuwenden und wird den gesamten
SCRUM Prozess massiv unterstützen. Sie sollten auf diese Vorteile keinesfalls verzichten.

DIE GUTE STORY: SO SIEHT SIE AUS

Eine Story sollte sich mindestens aus vier inhaltlichen Bestandteilen aufbauen, die ich nachfolgend kurz
Beschreibe:

1. MOTIVATION:

Die Motivation beschreibt, warum diese Story überhaupt gebraucht wird, welchen Wert das darin
beschriebene Feature aus Sicht des Product Owners (PO) für das Produkt hat aber auch welchen
Stellenwert diese Story im Entwicklungsprozess hat (z.B. der erste Proof of Concept für ein Modul
oder die abschießende Story, die die finale Fertigstellung des Projektes bedeutet). Da im Product
Backlog prinzipiell jede Story für sich alleine steht, der PO den Entwicklern gleichermaßen Vision
des Produktes und Leitfaden der Entwicklung liefern sollte, ist die Motivation der am besten
geeignetste Ort, genau das zu tun. Die Vision des Produktes zu verstehen, ist für Entwickler
unglaublich wichtig, wenn es darum geht weitsichtige Architekturentscheidungen zu treffen obwohl
ja gerade in frühen Phasen der Entwicklung noch gar nicht alle Stories vorliegen. Meiner Erfahrung
nach ist eine ausführliche Beschreibung der Motivation fast wichtiger als die Beschreibung des
Features an sich. In der Regel wende ich dafür mehr Text auf, als PO kann ich damit meine eigene
Intention sehr gut noch einmal überprüfen und im Sprint Planning zur Diskussion stellen. Wer sich
über die Motive seiner Handlung im Klaren ist, kann sein Handeln sehr gut Planen. Genau das gilt
für das Schreiben einer Story, wenn ich meine Motivation klar dargelegt habe, dass ist die
Beschreibung des Gegenstandes in der Regel wesentlich einfacher und vor allem konsistenter.

2. DESCRIPTION:
Auf die Motivation folgt die bereits oben angesprochene Description, die den Gegenstand dessen, was
entwickelt werden soll beschreibt. Auf das ‚Warum‘ (Motivation) folgt also das ‚Was‘ (Description). Oft werde
ich gefragt, wie eine perfekte Description aussehen soll, wieviel Text, welcher Stil, etc. Eine klare Antwort auf
diese Frage gibt es nicht, und zwar aus folgendem Grund: In meinem Beitrag über DAS WESEN VON
SCRUM hatte ich ‚Communication‘ als einen der vier wesentlichen Grundprinzipien für SCRUM
gekennzeichnet. Dies drückt sich in besonderer Weise in der Beschreibung der Stories aus. Die Art und
Weise wie eine Story beschrieben wird, drückt zu allererst den Stand der Kommunikation zwischen Team
und PO aus. Und diese verändert sich mitunter massiv im Verlauf eines Projektes, zumindest sollte es so
sein. Ein neues, junges, unerfahrenes Team zu Beginn eines Projektes benötigt ganz bestimmt sehr viel
detaillierte Beschreibungen in einer Story als ein Team, welches die Projektvision bereits perfekt adaptiert
hat, die Gedankengänge des PO’s sehr gut kennt und zu dem sehr tief in der Materie steckt. Letzterem
genügen mitunter ein paar einfache Skizzen und während des Plannings oder Groomings ein paar
begleitende Kommentare.
Gerade weil sich diese Kommunikation nach einigen Sprints und gut durchgeführten Retrospektiven ändern
wird, macht es keinen Sinn – und ist sogar kontraproduktiv – vor Projektstart bereits alle Stories fertig
beschrieben zu haben. Planen Sie besser 1 bis maximal 3 Sprints im Voraus, abhängig auch von der
gewählten Länge eines Sprints.
In der Description einer Story sollte alles erlaubt- und nahezu nichts verboten sein. Ob Sie ein UML Diagramm
verwenden oder Volltext schreiben, ein Mockup erstellen oder Links zur Konkurrenz nutzen bleibt ganz Ihnen
überlassen. Es muss zweckmäßig im oben genannten Sinn bleiben. Grundsätzlich empfehle ich folgende
Überlegung: IT im ganz Allgemeinen besteht aus drei Dingen: Daten, Prozessen und Interfaces. Wenn Sie
in der Description angeben welche Daten mit welchen Prozessen über welche Interfaces verarbeitet werden,
dann können Sie eigentlich nicht mehr so ganz falsch liegen.
3. ACCEPTANCE CRITERIAS:
Auf die Description folgen die Akzeptanzkriterien, die auflisten wann es gut ist, was da entwickelt wurde bzw.
unter welchen Umständen die Implementierung der Story abgenommen wird. Der häufigste Fehler der hier
von wenig erfahrenen PO’s gemacht wird ist zu sagen, dass das Akzeptanzkriterium ist, dass alles was
Implementiert wurde auch funktioniert, also quasi eine erneute Auflistung der Beschreibung. Das ist zwar
einfach und sehr naheliegend, aber nicht zielführend, denn das hätten sich die Entwickler eigentlich auch
denken können. Aber was ist nun mein Tipp um gute Acceptance Criterias zu schreiben. Ich habe zwei
Empfehlungen. Die erste ist, zwingen Sie sich zu jeder Story mindestens 3 bis 5 Acceptance Criterias zu
formulieren. Vergessen Sie dabei vor allem auch nicht die sogenannten ‚Non-Functional-Requirements‘,
also, dass die Funktion auf einer bestimmten Umgebung mit erwarteten Reaktionszeiten läuft, oder dass ein
durchschnittlicher Test-User die Anwendung intuitiv bedienen kann, etc. Meine zweite Empfehlung hat etwas
mit dem vierten und jetzt folgenden Abschnitt zu tun, daher erkläre ich diese gleich unten.
4. TEST CASES:
Testfälle beantworten die Frage, wie die Acceptance Criterias überprüft werden. Von Motivation über
Description und Acceptance Criterias bis zu den Testfällen liest sich das so: Warum will ich dieses Feature
haben (Motivation), Was soll implementiert werden (Description), wann ist die Implementierung erfolgreich
(Acceptance Criterias) und wie überprüfe ich das (Test Cases). So gelesen, ergeben die vier Bestandteile
eine logische Reihenfolge. Die oben genannte zweite Empfehlung für das Schreiben von Acceptance
Criterias ist also folgende: Überlegen Sie sich, wie Sie das Feature testen würden und was Sie als Ergebnis
der Tests erwarten würden. Und dann stellen Sie zwischen den Testfällen und den Acceptance Criterias eine
Entsprechung her. Bei der Erstellung der Testfälle achten Sie darauf, dass nicht nur der good-case getestet
wird, sondern auch alle Arten von abweichendem Verhalten der Anwendung oder der Anwender.
 DARF’S AUCH ETWAS MEHR SEIN? TESTDRIVEN DEVELOPMENT

Zum guten Schluss dieses Artikels, jetzt noch ein Tipp bzw. ein Trick über den Sie zumindest mal nachdenken
sollten. Ich hatte oben die vier Komponenten einer Story als eine logische Reihenfolge beschrieben.

Wenn Sie dem Projekt, Ihren Entwicklern, der Performance und der Qualität wirklich
einen Gefallen tun wollen, dann verändern Sie die Reihenfolge und gehen nach der
Motivation von unten nach oben.

Sie beschreiben also nach der Motivation sofort die Testfälle. Streng genommen können Sie sich dann die
Description und die Acceptance Criterias sogar sparen. Das Ganze nennt sich dann ‚testdriven development‘,
die Königsdisziplin der Softwareentwicklung, denn sie ermöglicht sehr schnelles und vor allem sehr präzises
Entwickeln. Kennt ein Entwickler bereits die Testfälle, gegen die er entwickeln soll und kann davon ausgehen,
dass diese auch vollständig sind, bleiben in der Regel keine Fragen offen und sie erhalten am Sprintende
sehr gute Resultate. Allerdings ist dieses ‚testdriven development‘ in der praktischen Wirklichkeit so selten
anzutreffen wie rotes Quecksilber, gleich einem Mythos. Das liegt in der Regel daran, dass POs das
Schreiben von Testfällen scheuen wie der Teufel das Weihwasser. In der Tat ist das kontinuierliche
Schreiben von vielen Testfällen keine triviale Angelegenheit. Es braucht Übung, es entlarvt alle
konzeptionellen Schwächen oder Informationslücken des PO, es erfordert eine sehr genaue Kenntnis des zu
implementierenden Geschäftsprozesses und man muss hier sehr diszipliniert arbeiten. Es ist technisch an
sich nicht schwierig, macht aber sehr viel Mühe und ich habe noch nicht viele POs gesehen, die ein solches
Commitment zu einem Projekt gegeben haben, dass sie mit ‚patriotischer‘ Freude diese Mühe gerne auf sich
genommen haben.
Überzeugen Sie mich bitte vom Gegenteil!
............................................................................................................................................................

PROJEKTMANAGEMENT VS. SCRUM

Seitdem der Begriff ‚agiles Projektmanagement‘ aufgetaucht ist, gibt es eine fortwährende Diskussion über
das Verhältnis von etablierten Projektmanagement Methoden (PMM) wie zum Beispiel PRINCE
2 oder PMI zu SCRUM als ein Vertreter der agilen Projektmanagement Methode. Dieser Artikel betreibt
etwas Projektmanagement Methodologie, ist also ein kleiner Beitrag zur Lehre der Projektmanagement
Methoden (PMM).
 SCRUM IST GAR KEINE PROJEKTMANAGEMENT METHODE

Die Frage die sich mir stellt ist nicht, wie gestaltet sich das Verhältnis von SCRUM zu z.B. PRINCE 2, also
wie ist das Verhältnis zwischen SCRUM und traditionellen PMM, sondern ob SCRUM überhaupt eine PMM
ist, wie der Überbegriff ‚agiles Projektmanagement‘ nahelegt. Warum ist das wichtig?
Unternehmen sehen sich oft genötigt, bei der Abwicklung von Projekten sich für eine bestimmte Methode zu
entscheiden. Oft ist dies sogar eine Frage von Konzern-Compliance-Richtlinien. Unternehmen, die SCRUM
gerne einsetzen möchten meinen, sie müssten sich entscheiden und Ihr geliebtes PRINCE 2 über Board
werfen, bzw. Ihre Compliance-Richtlinien ändern. So ein Unterfangen ist für große Konzerne alles andere
als ein Spaziergang sondern gleicht eher einem Jakobsweg. Was aber, wenn dieser Jakobsweg gar nicht
gegangen werden muss weil SCRUM keine PMM ist und somit auch nicht im Widerspruch zu anderen PMMs
stehen kann? Es geht hier allerdings nicht darum, Unternehmen durch einen Trick einen Ausweg aus dem
PMM Dilemma zu zeigen, sondern ein fundamentales Missverständnis bei der Bewertung von SCRUM als
agile PMM aufzudecken.
Das gut gemeinte Ersetzen einer PMM durch SCRUM im Projekt lässt in der Regel beide als Beschädigte
zurück: das Projekt, in dem wichtige Dinge nicht gemanagt werden und welches nicht erfolgreich verläuft,
und SCRUM die als PMM ob der vielen gescheiterten Projekte in Verruf gerät.

SCRUM IM PROJEKT, NICHT ALS PROJEKT

Ich sehe SCRUM als eine Software Implementierungs Methode (SIM), obwohl sich möglicherweise SCRUM
auch auf andere Industriezweige übertragen lässt. Im Grunde würde ich sagen, dass sich SCRUM auf alle
Prozesse übertragen lässt, die prinzipiell commitment- und completion-fähig sind. Was es genau mit
Commitment und Completion auf sich hat, können SieHIER in meinem Artikel über das Wesen von SCRUM
nachlesen. Als Software Implementierungs Methode (SIM) agiert SCRUM innerhalb eines Projektes, nicht
anstelle des Projektes. Vereinfacht betrachtet gibt es in einem Projekt neben der Abarbeitung eines Product
Backlogs sehr viele Aufgaben, die wesentlich zum Projekterfolg beitragen, von SCRUM aber nicht erfasst
oder abgedeckt werden. Einige davon beginnen, wenn das Projekt bereits initialisiert ist, die Entscheidung,
welche SIM (SCRUM oder Wasserfall) verwendet wird aber noch gar nicht getroffen worden ist. Dies ist eine
Aufgabe des Projektmanagements. Auch die Zusammenstellung der Teams, die initiale Budgetierung, die
Überwachung von Compliance-Richtlinien, das Projekt-Marketing, weite Teile des Projekt-Controllings, die
über die Analyse von Burndown-Charts hinausgehen fallen in den Aufgabenbereich des PMM und nicht in
den der SIM.
 WAS EIN PROJEKT FÜR SCRUM TUN MUSS

SCRUM selbst kennt nur die Rollen Product Owner, Scrum Master und Scrum Team und ist damit hoch
spezialisiert auf die Erstellung und Abarbeitung eines Product Backlogs. Diese Spezialisierung ist sehr
effektiv auf genau diese Aufgabe ausgelegt und versagt, wenn Dinge erledigt werden müssen, die nicht in
dieses Schema passen. Allgemein werden solche Dinge, wie z.B. Auseinandersetzungen mit Betriebsräten
über die Zulässigkeit des Time-Trackings oder der Zuweisung von Tasks zu Personen, plötzlich abgelaufene
Softwarelizenzen und deren Wiederbeschaffung von SCRUM als Impediment wahrgenommen, die den
Kernprozess stören und extern gelöst werden müssen. Dafür ist das Projekt da. Das Projekt schützt die
Implementierung als ihr „Allerheiligstes“, als das wahre Element der Wertschöpfung. Und dieses Projekt
bedient sich dafür einer PMM und bildet den Rahmen in dem SCRUM agiert. Die Herausforderung der PMM
ist, sich auf die Gegebenheiten der SIM anzupassen. Das muss sie sowieso, egal, ob Sie nach Wasserfall
oder nach SCRUM implementieren. Jede SIM hat seine Besonderheiten. Niemand wäre dabei auf die Idee
gekommen, Wasserfall als eine PMM zu betrachten und dieser Fehler sollte uns bei SCRUM auch nicht
unterlaufen.

VON PROJEKT- UND TEAMLEITERN

Allen Projektleitern, die sich schon als Scrum Master degradiert gesehen haben bzw. sich komplett in der
Überflüssigkeit wähnten, dürfte ich mit dieser Sichtweise gerade der Job gerettet haben. Spenden nehme
ich dafür gerne und dankend entgegen. Bei Teamleitern stellt sich das Ganze allerdings ganz anders dar,
falls Sie nicht gerade in einer Matrixorganisation leben. SCRUM baut im Implementierungsprozess ganz
bewusst Bürokratie und Hierarchien ab, eliminiert Micro-Management und ersetzt sie durch eine sehr
effektive Selbstorganisation crossfunktionaler Teams, die nach anderen Regeln funktionieren kann als die
sich darum organisierende Projektstruktur. Sie kann sogar andere kulturelle Werte hervorbringen, die gerade
aus dieser verantwortungsvollen Selbstorganisation erwachsen. Projektorganisationen sind hier gut beraten,
diesen kulturellen Change zu fördern und in der Unternehmensorganisation zu vermitteln. Eine
Herausforderung, die großen Konzernen oft sehr schwer fällt und Grund genug für diese, SCRUM
grundsätzlich ein ungerechtfertigtes Misstrauen entgegenzubringen. Die Projektleitung muss genau dieses
im Blick haben, bevor sie sich für SCRUM als SIM entscheidet.

Das Unternehmen oder auch das Projekt muss SCRUM fähig gemacht werden.
............................................................................................................................................................

VERKAUFE SCRUM ZUM FESTPREIS

Es gibt einen Grund, warum besonders Großkonzerne SCRUM scheuen. Nicht, dass sie SCRUM nicht
einsetzen, aber oft mit nur wenig Überzeugung und noch häufiger eher als Getriebene aus einer Not heraus.
Der Vorwurf: SCRUM Projekte sind schlecht planbar und schon gar nicht Festpreis-fähig. Begründet wird
das mit der Methodologie selbst, in der funktionale Anforderungen vor Implementierungsstart als Stories im
Product-Backlog nur grob beschrieben sind und Überlegungen zur Architektur und Technologie oft noch gar
nicht stattgefunden haben. Somit ist die Methodologie dem Management in großen Projekten, die zumeist
mit festen Budgets ausgestattet (intern)- bzw. als Festpreis angeboten (extern) werden müssen, schwer zu
verkaufen. Zu hoch scheinen die Risiken einer Fehlkalkulation. Dennoch gibt es zunehmend mehr Projekte,
die in klassischer Weise nicht mehr vorgeplant werden können, sei es, dass die Zeit fehlt, oder die
Komplexität zu hoch ist inklusiver großer Vernetzung mit anderen Systemen und den daraus schwer
einschätzbaren Abhängigkeiten. Scheinbar ein Dilemma und Grund genug, hier einen Weg aufzuzeigen, wie
SCRUM – Projekte festpreisfähig gemacht werden können.
Ein Festpreisangebot für ein Software Entwicklungsprojekt abzugeben ist ohnehin eine große
Herausforderung. Es erfordert eine genaue Kenntnis über die funktionalen Anforderungen des Kunden, die
einzusetzenden Technologien, die betroffenen Schnittstellen, die geplante Architektur, die Skills der eigenen
Mitarbeiter, die Möglichkeit paralleler Entwicklung etc. Wie wir später noch sehen werden, haben deutlich
über hundert Faktoren Einfluss auf die tatsächlich zu erbringenden Entwicklungsaufwände. Dies gilt für jedes
Projekt egal welche Methodologie zum Einsatz kommt. Hinzu kommt das oben erwähnte SCRUM Handicap
der nur grob beschriebenen funktionalen Anforderungen zum Zeitpunkt der Projektplanung. An dieser Stelle
möchte ich noch gleich mit einem leider weit verbreiteten Missverständnis aufräumen, falls Sie sich auch
gerade an dem Begriff „Projektplanung“ im Zusammenhang mit SCRUM gestoßen haben. SCRUM ist eine
Implementierungsmethodologie, keine Projektmanagement Methodologie, d.h. SCRUM funktioniert
innerhalb eines Projektes nicht anstelle des Projektes bzw. als Projekt selbst. Das beantwortet dann auch
die Frage, ob in SCRUM noch Projektleiter benötigt werden und solche Dinge wie Projektpläne, Review
Boards, jour fixe und vieles mehr. Ja, sie werden, allerdings müssen sie auf den Einsatz der gewählten
Implementierungsmethodologie zugeschnitten werden. Das gilt sowohl für die Projektrollen, als auch für die
Projektsteuerungsinstrumente.

ZUM FESTPREIS IN DREI SCHRITTEN

Zurück zum Festpreis Problem und zu einem Vorschlag, wie sie es lösen können, denn das ist durchaus
möglich. Um die Aufgabe zu bewältigen empfiehlt es sich, die Komplexität zu reduzieren und das gelingt uns
durch die Einnahme einer SCRUM-typischen Perspektive: Eine Software wird über ihre Featues
beschrieben, nicht über ihre Technik, Architektur, Layer oder was auch immer. Wir betrachten den
Funktionsumfang getrennt von deren Implementierung und versuchen für beides jeweils ein Maß zu finden.
Kurz, um ein Festpreis für ein Softwareprojekt zu ermitteln benötigen wir in unserem Ansatz drei
Informationen:
Ein Maß für den Scope, sprich die funktionale Größe der zu entwickelnden Software
Ein Maß für Aufwand, den Sie betreiben müssen, um Funktionalität zu implementieren
Ihre Kosten und Preise

Letzteres können wir in unserer Betrachtung vernachlässigen, denn Ihre Kosten pro „managed workplace“,
sollten Ihnen bekannt sein. Falls nicht, hätten Sie ein grundsätzliches Problem und müssten
betriebswirtschaftlich nochmal ganz von vorne anfangen.
Der erste Punkt repräsentiert die SCRUM-typische feature orientierte Sichtweise, während der zweite Punkt
die oben bereits erwähnten über hundert Faktoren behandelt, die Einfluß auf den tatsächlichen
Entwicklungsaufwand pro Funktionseinheit haben. Einige davon sind die einzusetzenden Technologien, die
grundsätzliche Architektur (z.B. Client Server oder SOA), die Skills der Entwickler, die Kommunikation mit
Ihren Kunden, der Einsatz von Nearshoring oder Offshoring, die Art Ihrer Unternehmensorganisation (z.B.
Matrixorganisation), Ihre CI-Strategie, die Anzahl und Verfügbarkeit von Testsystemen und Testdaten, die
geplante Projektdauer, die Anzahl von Entwicklern, die Projektsprache und vieles mehr. Viele dieser Faktoren
sind unternehmensspezifisch, andere (aber auch viele) sind projektspezifisch.

SCHNELL ODER PRÄZISE: ‘STORY POINTS’ ODER ‘FUNCTION POINTS’

Der Funktionsumfang einer zu entwickelnden Software wird in SCRUM üblicherweise in Form von Features
beschrieben. Ein Feature beschreibt, was entwickelt werden soll, nicht wie es implementiert wird. Alle
Features werden in einem Product Backlog zusammengeführt. Damit ist der Scope vollständig, wenn auch
sehr grob beschrieben. Nun gilt es für diesen Funktionsumfang ein möglichst objektives Maß zu finden,
welches später als Faktor in unserer Gleichung zur Anwendung kommen kann.
SCRUM kennt so ein Maß: die Story Points. In der Literatur werden Story Points allgemein als eine Einheit
für die Komplexität – gemeint ist hier konkret der Implementierungsaufwand – einer Story eingeführt. Und
damit werden Story Points für das Vorhaben, für den im Product Backlog definierten Scope einen Festpreis
zu ermitteln, sehr problematisch. Überhaupt ist die Anwendung von Story Points in der Theorie noch
einigermaßen einleuchtend begründet, in der Praxis allerdings umstritten. Warum? Erstens repräsentieren
Story Points kein objektives Maß sondern sind eine rein subjektive Maßeinheit, die den relativen
Komplexitätsgrad (sprich Implementierungsaufwand) einer Story lediglich im Verhältnis zu anderen Stories
angibt. Anders als in der öffentlichen Diskussion um Story Points halte ich das für sich genommen noch nicht
für problematisch, zumindest dann nicht, wenn ich hier „subjektiv“ mit „team- und projektspezifisch“
übersetzen kann und davon ausgehe, dass auch das Team diese Einschätzung trifft.
Das Problem liegt eher in der Einheit selbst, nämlich als Einheit für die Komplexität einer Story. Denn damit
wird die Perspektive gewechselt, weg von der funktionalen Größe (Scope) und hin zum
Implementierungsaufwand bzw. wird die in SCRUM nahegelegte Trennung zwischen funktionaler
Anforderung und dem Aufwand ihrer Implementierung aufgehoben. Damit wird der oben beschriebene
Ansatz der Reduktion von Komplexität gleich wieder aufgegeben und bei der Bewertung der Story hinsichtlich
ihrer Komplexität müssen die oben beschriebenen über hundert Faktoren sofort wieder mitgedacht werden.
Dies aber kann zu einem anderen Zeitpunkt als dem Sprint-Planning, in dem sich das Team intensiv mit der
Schätzung der Story beschäftigt, nicht hinreichend geleistet werden. Zum Zeitpunkt des Sprint-Plannings
aber, könnte als Einheit dann auch gleich Stunden verwendet werden. Sollen Story Points also für die
Festpreis Findung verwendet werden, dann müssen sie mindestens viel früher geschätzt werden. In der
Regel passiert das durch einen erfahrenen Architekten, dem dann aufgebürdet wird, sowohl die funktionale
Größe als auch die vielen anderen Faktoren in Einem einzuschätzen. Ich denke es ist leicht nachvollziehbar,
dass diese Übung zwar schnell ausgeführt werden kann, allerdings mindestens nur sehr ungenaue
Schätzwerte liefert.
Es gibt eine andere Möglichkeit, ein geeignetes Maß zu ermitteln: die Function Point Analyse. Hinter Story-
Points und Function-Points stehen fundamental andere Konzepte. Kurz gesagt, während Story-Points eine
subjektive Einheit für die Komplexität einer Story ist, sind Function-Points ein objektives – also team- und
projketunabhängiges – Maß für die reine funktionale Größe einer Anforderung. Funktionale Anforderungen
werden damit unmittelbar vergleichbar, egal ob sie zum Beispiel völlig neu entwickelt werden, oder in einer
bereits existierenden, historisch gewachsenen und schlecht dokumentierten Anwendung mit weitreichenden
Refactorings hineinimplementiert werden. Wir alle wissen, dass allein zwischen diesen beiden Szenarien im
Extremfall Aufwandsfaktoren im zweistelligen Bereich liegen können. Function-Points sind ein weitestgehend
objektives Maß, da sie nicht geschätzt, sondern nach klaren und einfachen Regeln gezählt werden. Die
Einschränkung ‚weitestgehend‘ unterstellt, dass es bei der Interpretation der Zählregeln gewiss auch
Spielräume gibt. Untersuchungen zufolge sind diese bei erfahrenen Function-Point-Analysten nicht größer
als 10 Prozent. Das Zählen von Function-Points macht allerdings mehr Mühe. Aber die Mühe lohnt sich. In
einem meiner Großprojekte (50 Entwickler, 3 Jahre Entwicklungszeit) hat das Zählen von ca. 8.000 Function
Points für einen Function-Point-Analysten ca. 2 Wochen in Anspruch genommen. Bei einem 30 Mio Euro
Projekt ist das durchaus akzeptabel. Ein weiterer Vorteil ist, dass der bei der Zählung erstellte Funktionsbaum
direkt für die Erstellung der Stories verwendet werden kann, was später das Projekt-Controlling und Scope-
Management ganz wesentlich vereinfacht.
 AUFWANDSCHÄTZUNG

Wenn Sie die funktionale Größe Ihres Projektes anhand der einzelnen funktionalen Anforderungen Ihres gut
gepflegten Product-Backlogs und der Summe der Fuction-Points der einzelnen Backlog-Items ermittelt
haben, sind Sie schon einen großen Schritt vorangekommen. Sie müssen jetzt nur noch einen Preis für die
Implementierung eines Function-Points festlegen und dazu den Aufwand ermitteln. Hier bieten sich prinzipiell
zwei Wege an. Sie können einfach in einem Vorprojekt einen Proof-of-Concept erstellen, indem Sie einen
kleinen Prototyp entwickeln und daran die Gesamtkosten ermitteln. Das hat zwei Vorteile. Erstens können
Sie am Ergebnis Ihre ursprüngliche Function-Point-Zählung verifizieren. Zweitens erhalten Sie für die
Aufwände reale Werte, sofern Sie sicherstellen können, dass der Proof-of-Concept tatsächlich repräsentativ
ist. Genau hierin liegt aber oft das Problem, sodass ein solcher Proof-of-Concept nicht immer möglich ist.
Der dann nahe liegende zweite Weg ist die Anwendung einer Schätzmethode, die all die bereits mehrfach
oben erwähnten Einflussfaktoren berücksichtigt. Die COCOMO (Constructive Cost Model) Schätzung
beispielsweise ist so ein algorithmisches Kostenmodell, welches genau das leistet. Die Anwendung ist sicher
nicht ganz trivial, die Schätzungen sind allerdings von hoher Präzision und vermindern die wirtschaftlichen
Risiken signifikant und Sie können Ihren Kunden und Ihrem Management ruhigen Gewissens (weil absolut
nachvollziehbar) Ihren Festpreis präsentieren.

SCOPE CHANGES

Die Vorgehensweise, den funktionalen Scope Ihres Projektes mit einem objektiven Maß, den Function-Points
zu beschreiben und dann einen Preis für die Implementierung eines Function-Points zu ermitteln hat noch
einen ganz entscheidenden Vorteil, der sich insbesondere in Projekten, in denen SCRUM zum Einsatz
kommt, auszahlt. Sie können Ihren Kunden ganz pauschal und abstrakt die Entwicklung von Funktionalität
zum Festpreis anbieten, selbst wenn diese noch gar nicht definiert ist. Da Sie wissen, was die
Implementierung von Funktionalität (Function-Points) unabhängig von der konkreten funktionalen
Anforderung kostet, können Sie jeden Scope Change sehr einfach und transparent handeln. Sie vereinbaren
mit Ihrem Kunden, dass der Preis für eine bestimmte Anzahl von Function-Points gilt und falls der Kunde bei
der Ausgestaltung der einzelnen Stories im Verlauf des Projektes diese Zahl überschreitet, also der Scope
erweitert wird, erhöht sich der Preis entsprechend automatisch. Im Gegenzug erhält der Kunde die
Möglichkeit durch Priorisierung aktives Scope-Management zu betreiben und für jede Story den funktionalen
Umfang sehr fein zu steuern.
Da es sich bei der Function-Point-Analyse um eine neutrale und objektive Zählung handelt, können Sie mit
Ihren Kunden bei Bedarf auch einen unabhängigen Function-Point-Analysten, der das Vertrauen beider
Parteien genießt, einbinden. Projekte dieser Art verlaufen in der Regel erheblich stressfreier, da sich der
Kunde auf den Scope konzentrieren kann und der Dienstleister sich einzig mit der Implementierung
beschäftigen muss, was in der Regel bereits herausfordernd genug ist.
............................................................................................................................................................

DAS WESEN VON SCRUM: DIE 4 C’S

SCRUM ist eine Software-Implementierungs-Methodologie innerhalb eines Software-Entwicklungsprojektes,

welche besonders auf die Effektivität der Implementierung fokussiert und daher eine streng Feature-
orientierte Entwicklung nahelegt. Warum das so ist habe ich in meinem Beitrag „EFFEKTIVITÄT STATT
EFFIZIENZ: DER KOMPROMISS SCRUM“ begründet. Und ein Projekt sollte gute Gründe haben, diese
Methodologie einer anderen vorzuziehen, denn sie ist nicht per se die allerbeste und immer einzusetzende
Methodologie.
Wie aber funktioniert sie und warum? Es genügt mir nicht – wie häufig in der einschlägigen Literatur
geschehen – zu beschreiben, wie die Artefakte (Rollen, Sprints, Daily SCRUMS, etc.) implementiert werden
und wie sie anzuwenden sind. Es ist vielmehr zunächst wichtig zu verstehen, warum es sie überhaupt gibt
bzw. warum sie zwangsläufig erforderlich sind, um erfolgreich zu sein. Sie werden es sich dann nämlich
zweimal überlegen, ob sie hier oder da gewisse Dinge ‚customizen‘, bzw. werden sie abschätzen können,
ob das überhaupt sinnvoll oder möglich ist und welchen Impact sie erwarten dürfen.
Damit die ganze Sache kurz, pointiert und halbwegs unterhaltsam bleibt, habe ich das Modell der 4 C’s
entworfen. Keine Angst, es ist immer noch pures SCRUM und nicht meine persönliche Variante. Es ist nur
eine bestimmte Art, SCRUM zu vermitteln und ich hoffe, Sie finden sie ebenso einleuchtend wie logisch.
Die ersten beiden C’s stehen für Commitment und Completion. Sie bilden die statischen Säulen, das
Paradigma auf das SCRUM aufsetzt. Die zwei anderes C’s stehen für Communication und Common Sense.
Common Sense, ja Sie haben richtig gelesen. Die Anwendung gesunden Menschenverstandes ist bei der
Durchführung schon die halbe Miete! Communication und Common Sense sind die dynamischen
Komponenten und beschreiben wie SCRUM implementiert wird. Zwei Paradigmen und zwei Techniken, mehr
braucht es eigentlich nicht.

Kurz gesagt: Wenn wir in einem Software-Entwicklungsprojekt die Werte Commitment

und Completion als höchstes Gut setzen und dann gesunden Menschenverstand
(common sense) und eine bestimmte Art der Kommunikation einsetzen, dann kommen
wir ganz automatisch auf die SCRUM Methodologie mit allen Artefakten, Prozessen etc..

COMMITMENT & COMMON SENSE IN SCRUM

 SCRUM TEAM

Wenn es mir in meinem Projekt darauf ankommt, ein klares Commitment zu erhalten, dann wäre es
vernünftig, z.B. den Entwicklungsaufwand von denjenigen bestimmen zu lassen, die die Entwicklung
durchführen. Und diejenigen müssen dabei selbst entscheiden dürfen, wie sie die Anforderungen umsetzen.
So sind die selbstbestimmten SCRUM-Teams geboren.

COMMITMENT

Natürlich macht es am meisten Sinn, diese Commitments auf möglichst kleine Einheiten zu beschränken, die
von einem Team gut zu überblicken sind. Also führen wir besser kurze Sprints durch, denen jeweils ein
Grooming und Planning vorangestellt wird, um dieses Commitment zu kreieren.

DAILY SCRUMS

Dann wiederum wollen wir sicherstellen, dass dieses Commitment während eines Sprints auch gehalten wird.
Daily Scrums, also kurze tägliche Standup Meetings sind nicht dafür da, dass sich Teams täglich guten
Morgen sagen oder ein Wir-Gefühl erzeugen, oder sich erzählen, was sie gestern so getan haben oder heute
tun wollen. Das passiert zwar, ist aber nicht der Zweck. Der Zweck ist, das am Sprint-Anfang gegebene
Commitment täglich zu erneuern. Sind wir noch im Plan oder droht Gefahr durch Verzug und falls ja, wie
kommen wir wieder zurück auf die Bahn und stellen das Commitment sicher. Damit ein Projektleiter das
verfolgen kann, sind Sprint-Burndown Charts nützlich. Und ich brauche natürlich einen Moderator für diesen
Prozess. Nennen wir ihn mal:

SCRUM MASTER

Er ist nicht dafür verantwortlich, dass das Team Prozess-konform arbeitet. Das tut er zwar, aber das ist nicht
der Zweck. Prozesskonformes Arbeiten ist ja kein Selbstzweck. Der Zweck ist, das Team Commitment-fähig
zu halten. Denn das Commitment wurde auf der Prämisse erteilt, dass für den Sprint die Ressourcen
verfügbar sind und nicht gestört werden und diese ohne Störung von äußeren Einflüssen arbeiten können.
Wir sehen also, dass sich nahezu alle Rollen und orgnisatorischen- oder administrativen Artefakte direkt vom
Paradigma Commitment ableiten lassen. Sollten Sie also irgendetwas an Ihrer Methodologie customizen
wollen, fragen Sie sich zuerst, ob das Team dann noch Commitment-fähig bleibt. Das gilt insbesondere für
all die Fälle, wo Ressourcen temporär aus einem Sprint abgezogen werden, in der Regel für irgendwelche
ungeplanten Workshops, Fehlerbeseitigungen, Präsentationen, Wartungsarbeiten, etc.
 COMPLETION & COMMON SENSE IN SCRUM

Nun ist es auch wichtig, dass ein Commitment nicht nur gehalten wird, sondern auch überprüft werden kann.
Damit ich etwas überprüfen kann wäre es vernünftig, wenn etwas fertig gestellt ist. Aus meiner
Projektmanagement Praxis weiß ich natürlich, dass es bei Entwicklern circa ebenso viele Definitionen für den
Begriff ‚fertig‘ gibt, wie bei den Eskimos für den Begriff ‚Schnee‘.
„Ich bin fertig, muss nur doch dokumentieren“
„Ich bin fertig, muss da morgen aber noch mal was nachsehen“
„ich bin im Prinzip fertig“ – was oft bedeutet, dass noch gar nicht angefangen wurde
„ich wäre fertig, wenn nicht… (was jetzt kommt, können Sie sich aussuchen)“
„ich bin fertig, aber der letzte Test schlug leider fehl“. Die Liste ist fast endlos.

Wenn Sie eine STORY beschreiben, dann sind vier Informationen wichtig:

1. MOTIVATION

Die ‚Motivation‘ sagt, warum dieses Feature überhaupt gebraucht wird. Diese Information ist wichtig, um den
Entwicklern eine Vision zu vermitteln, es hilft ihnen den Stellenwert des Features zu beurteilen und daraufhin
grundlegende Architekturentscheidungen zu treffen.

2. DESCRIPTION

Die darauf folgende ‚Description‘ sagt, was hier eigentlich gebaut werden soll und ist wichtig, um den Scope
einzugrenzen. Grober Leitfaden: IT im ganz Allgemeinen besteht aus 3 Elementen: Daten, Prozessen und
Interfaces. Beschreiben Sie also welche Daten über welche Interfaces in welchen Prozessschritten
verarbeitet werden. Dann liegen Sie bestimmt nicht ganz falsch bei der Beschreibung der Story.

3. ACCEPTANCE CRITERIAS

Die ‚Acceptance Criterias‘ sagen, wann es gut ist, was da gebaut werden soll. Sie legen fest, wann das
Feature fertig entwickelt ist, sie sind also die einzig gültige Definition des Begriffs ‚fertig‘.

4. TESTCASES

Und schließlich die ‚Testcases‘. Sie sagen, wie Sie denn überprüfen, ob es auch wirklich gut ist und damit
fertig, was da gebaut wurde.
Und da haben wir auch gleich eine valide Definition des Begriffs fertig.
 Eine Story ist dann fertig, wenn ihre Implementierung den Acceptance Criterias
entspricht und alle dafür erstellten Testfälle bestanden wurden.

Dies setzt natürlich voraus, dass Acceptance Criterias überhaupt beschrieben wurden sowie ausreichend
und aussagefähige Testfälle vorliegen. Oft große Probleme für den Product Owner.
Nur über den Begriff ‚Completion‘ können Sie das Commitment überprüfen. Und daher gilt im Scrum die
Regel, dass es nicht ok ist, Stories am Ende eines Sprints offen zu lassen. Das heißt, wenn Sie im Sprint 5
Stories haben und nicht fertig werden können, dann schließen Sie besser so viele wie möglich vollständig ab
und andere bleiben dafür ganz offen, als dass Sie alle Stories ‚fast fertig‘ machen. Und damit das getan
werden kann, brauchen wir in SCRUM natürlich crossfunktionale Teams und priorisierte Stories, damit in
einem solchen Fall der Umpriorisierung andere Teammitglieder daran weiterarbeiten können. Das ist dann
übrigens auch der Grund, warum im Sprint-Planning jede Story von jedem Teammitglied geschätzt wird, und
sich das ganze Team einig sein muss. Das ist keine teambildende Maßnahme, sondern eine notwendige
Voraussetzung, um später das Commitment halten zu können.
Wir sehen also, auch die Artefakte ‚Story‘, ‚Crossfunktionalität‘, ‚Planning Poker‘ und ‚Review‘ leiten sich
direkt aus den Paradigmen Commitment und Completion ab, nur durch Anwendung gesunden
Menschenverstandes.

COMMUNICATION

Nun haben wir noch nicht über das dritte C gesprochen, dabei ist es der Schlüssel zu allem. Und gleichzeitig
macht es auch die meisten Probleme weil es am schwierigsten zu fassen ist. Communication meint hier nicht,
dass viel miteinander kommuniziert wird und dass Kommunikation über Dokumentation steht. Das stimmt
zwar und passiert auch so, ist hier aber so nicht gemeint. Es geht vielmehr um die Art der Kommunikation,
um die Perspektive und den Rhythmus. Und diese reflektiert und gleichzeitig definiert den Unterschied einer
vertikalen, feature-orientierten zu einer horizontalen, layer-orientierten Entwicklung, wie in meinem oben
erwähnten Beitrag beschrieben. SCRUM führt in die Kommunikation für viele Software-Experten einen
Perspektivwechsel ein.

Im Zentrum der Kommunikation steht der Begriff ‚Business Value‘.

Und diese Perspektive zieht sich durch die gesamte Methodologie vom zentralen feature-orientierten Ansatz,
der sich aus dem Paradigma Effektivität herleitet bis runter zur Beschreibung und Priorisierung von Stories,
die sich aus der Beschreibung der ‚Motivation‘ herleiten. Wenn SCRUM gut eingeführt ist, verändert sich
nach zwei bis drei Sprints die Kommunikation in genau diese Richtung. Wir möchten, dass alles was wir in
SCRUM tun, aus dieser Perspektive betrachtet wird, wenn wir eine Story erstellen, wenn wir eine
Architekturentscheidung treffen müssen, wenn wir Kompromisse bei der Umpriorisierung von Stories
eingehen müssen, etc. Diese Perspektive ist in einer horizontalen, layer-orientierten Entwicklung praktisch
unmöglich, hier wird dem Grundgedanken der Effizienz entlang viel technischer kommuniziert, es geht dabei
mehr um technische Machbarkeiten und Risiken, etc. Sehr oft (nicht immer und auch nicht notwendiger
Weise) tritt der Zweck dabei in den Hintergrund bzw. bleibt implizit.

SCRUM funktioniert nur, wenn alle Akteure bereit sind, sich auf diese Art der
Kommunikation einzulassen und sie einzuüben.

Wenn Sie bemerken, dass Product Owner und SCRUM Team komplett aneinander vorbeireden, dann wissen
Sie, dass dieser Perspektivwechsel schlicht noch nicht stattgefunden hat. Darüber hinaus brauchen Product
Owner und Scrum Team eine gewisse Zeit, sich zu verstehen.

Die Stories müssen genauso beschrieben werden, dass Entwickler sie verstehen und
unmittelbar mit der Implementierung beginnen können.

Stories spiegeln also den Stand der Teamkultur wieder, die sich über Kommunikation manifestiert. Extrem
gut harmonisierende Teams brauchen in den Stories nicht viel Text, untrainierte Teams brauchen viel
ausführlichere Beschreibungen. Das hat oft mit der Komplexität des Gegenstandes gar nichts zu tun, sondern
spiegelt vielmehr den Stand der Kommunikation des Teams wider. Retrospektiven helfen, um kommunikative
Schwachstellen aufzudecken und genau diese zu verbessern. Auch dieser Prozess dauert etwas und ist der
Grund dafür, dass oft die ersten paar Sprints noch nicht so erfolgreich sind. Da darf der Projektleiter nicht die
Nerven verlieren sondern muss auch mal geduldig bleiben.
Sie können nun die 4 C’s quasi als Leitfaden für die Implementierung der Methodologie in Ihrem Projekt oder
bei der Lösung praktischer Probleme verwenden.

Denken Sie bei Ihren Entscheidungen nur daran welches der C’s betroffen ist und es
wird Ihnen leichter fallen, die Auswirkungen abzuschätzen und bessere Entscheidungen
zu treffen.
............................................................................................................................................................

EFFEKTIVITÄT VS. EFFIZIENZ

EFFEKTIVITÄT IST DIE NEUE PERSPEKTIVE

Für alle SCRUM Fans die schlechte Nachricht zuerst: SCRUM ist nur ein Kompromiss. Die gute Nachricht,
dies ist die einzige schlechte Nachricht. Allerdings eine mit weitreichenden Folgen. Zum Beispiel die, dass
viele Entwickler alles, was sie über Softwareentwicklung zu wissen glaubten über Bord werfen müssen und
das Handwerk quasi neu lernen müssen. Der Grund dafür liegt im Wesen dieses Kompromisses begründet
und sollte sehr ernst genommen werden. In der Praxis wird er selten ernst genommen, weil oft nicht wirklich
verstanden und das führt in vielen SCRUM Projekten zu herben Enttäuschungen. Es ist Ziel dieses Posts,
Ihnen diese Enttäuschung zu ersparen. Die Zauberformel dafür heißt Effektivität statt Effizienz. Alle, denen
der Unterschied zwischen Effektivität und Effizienz nicht mehr ganz geläufig ist, frischen HIER ihre
Erinnerung kurz auf.
Im – sagen wir mal – klassischen Entwicklungsprozess versuchen wir uns eine perfekte Welt zu schaffen,
indem wir erst eine Grob- und dann eine Feinspezifikation erstellen, diese diverse Review-Prozesse und
Approvals schicken, dann ein Architektur-Modell entwerfen, etc. Kurz, der Projektgegenstand wird
transparent gemacht, und damit sehr planbar. Das kostet zwar Zeit und Geld, aber es ermöglicht uns, sehr
effizient vorzugehen. Effizientes Vorgehen bedeutet, ein optimales Verhältnis aus Input und Output
herzustellen, welches voraussetzt, dass ich genau weiß, was ich tun muss und mein Tun genau planen kann.
In der Regel führt dies zu einer sehr optimierten horizontalen, also Layer-orientierten Entwicklung (z.B.
Datenbank, Daten-Zugriffs Layer, Business Logik Layer, GUI Layer).
Was aber wenn Sie nicht die Zeit oder das Geld haben, diesen mitunter langwierigen Prozess zu
durchlaufen? Eine perfekte Welt schafft man nun mal nicht eben mal so im Vorbeigehen. Oder Ihnen fehlen
die Ressourcen oder das Wissen darum, wie man eine solche perfekte Welt beschreibt. Vielleicht wissen Sie
aber auch schon, dass sich die Anforderungen im Verlauf des Projektes ändern können, weil sie auf
Marktsituationen reagieren können müssen.
Und schlimmer noch: Im 21. Jahrhundert ist Software wesentlich komplexer geworden. Sie ist außerdem oft
viel vernetzter und Time-to-Market Anforderungen sind heute auch deutlich höher und oft wirken alle drei
Faktoren gleichzeitig. Ein Teufelskreis. Denn eigentlich sind diese Faktoren die Gründe warum man gerade
eine perfekte Welt schaffen sollte in der man dann sehr effizient vorgehen kann.
 Projektleiter stehen vor einem Dilemma und
ein Kompromiss muss her: SCRUM.

EFFEKTIVTÄT ALS KOMPROMISS IN SCRUM

SCRUM ist ein Kompromiss, den wir eingehen, wenn wir keine perfekte Welt vorliegen haben, aber dennoch
ein Projekt erfolgreich durchführen wollen. Da wir aber ohne diese perfekte Welt aus Feinspezifikationen,
Architekturmodellen, etc. nicht effizient sein können verschiebt SCRUM den Fokus von der Effizienz in
Richtung Effektivität, d.h. die Erreichung eines angestrebten Ziels ist wichtiger als die Herstellung eines
perfekten Verhältnisses zwischen Input und Output. Dieser Kompromiss hat seinen Preis. Denn dieser
Kompromiss, die Fokussierung auf die Effektivität statt Effizienz, bringt einen Paradigmenwechsel mit sich:
weg von der Effizienz der horizontalen-, also Layer-orientierten Entwicklung und hin zur Effektivität der
vertikalen-, also Feature-orientierten Entwicklung.
Und diesen Preis bezahlen zuerst die Entwickler, die nicht nur weite Teile ihres Handwerks neu lernen
müssen, auch die Anforderungen an Entwickler steigen enorm. Ein Umstand übrigens, den Projektleiter bei
der Zusammenstellung ihrer Teams oft komplett übersehen. Entwickler müssen nun die Vision des gesamten
Projektes mindestens grob kenn, sie müssen ein Feature end-to-end denken, sie müssen in der Lage sein,
es durch alle Schichten hindurch zu entwickeln und dabei gleichzeitig die Architektur künftiger Features im
Blick behalten, damit später nicht zu viel refactored werden muss. Untrainierte Teams stoßen da oft schnell
an ihre Grenzen und es braucht ein paar Sprints um Teams an diese Herausforderung heranzuführen
(siehe Wie trainiere ich ein Team in Scrum). Nicht wenigen Managern und Projektleitern fehlt aber eben dafür
die Geduld. Das Mittel der Wahl heißt hier intensives Prototyping.
Zum Schluss möchte ich noch mit einem weit verbreiteten Missverständnis aufräumen. Oft wird verbreitet,
dass SCRUM wesentlich flexibler ist, dass in SCRUM mehr „getalked“ wird (ich gebrauche hier ganz bewusst
diesen etwas schrägen denglischen Begriff) und weniger dokumentiert, dass wir flache Hierarchien haben,
bzw. gar keine. Mag alles sein. Fatal ist nur, dass oft dadurch der Eindruck eines gewissen „laissez faire“
entsteht, der in SCRUM Projekten gepflegt werden kann. Das ist ganz falsch! SCRUM erfordert ein
Höchstmaß an Disziplin. Als Kompromiss in einer nicht perfekten Welt ist SCRUM ohnehin schon schwer
belastet und damit ein fragiles Gebilde. Noch mehr Kompromisse beim Umgang mit SCRUM verträgt diese
Methodologie nicht, der Vorrat an Kompromissen wurde bereits beim Setup aufgebraucht. Der Rest muss
jetzt wesentlich stringenter und präziser, vor allem aber disziplinierter ablaufen.

Bleiben Sie effektiv!