SCRUM
SCRUM seht hier als Synonym für alle agilen Projekt- und Softwareentwicklungs- Methodiken. SCRUM basiert – sehr kurz und etwas provokant formuliert – auf der Idee, dass Sie sich eine lange Spezifikationsphase sparen können und sofort und in einem iterativen Prozess mit der Entwicklung von Software starten.
Während eine gute Spezifikation Effizienz ermöglicht, bedeutet der Verzicht darauf zu Gunsten eines schnellen Entwicklungsstarts Effektivität. Die Langversion dieser extrem verkürzten Darstellung können Sie hier nachlesen:
SCRUM ist nicht nur fancy und vielleicht auch etwas riskant, SCRUM ist heute zunehmend alternativlos,
was die Brisanz dieses Themas wesentlich erhöht.
Die gewaltige Zunahme der Komplexität von Software in 21. Jahrhundert mit der zeitgleichen Abnahme an Zeit, die Ihnen der Markt gewährt, um Ihr Produkt einzuführen, wurden Wasserfall-Methodiken zum Auslaufmodell. Und – abgesehen davon, dass wir alle das auch genauso wollen, sonst würden wir da ja nicht aktiv mitspielen – das ist auch gar nicht schlimm. SCRUM Projekte sind in der Regel tatsächlich schneller und günstiger.
Aber – und sonst wäre es ja viel zu einfach – sie haben den Nachteil, dass sie deutlich schwieriger planbar sind. Und genau dieser kleine Schönheitsfehler kollidiert mit den neuen Richtlinien, die das AÜG nun einführt.
Im Zentrum der Änderungen des AÜG stehen zwei Punkte:
Agile in a day
Wir trainieren Ihr Team, coachen Ihre Stakeholder und führen Ihr Projekt zum Erfolg.
Wo liegt das Problem?
In der Branche ist es üblich, größere IT Projekte mit externen Mitarbeitern zu besetzen, die oft über die großen Recruiting-Unternehmen bezogen werden. Oder sie kommen von kleineren IT-Partnern, die oft nicht selbst an Projektausschreibungen teilnehmen, sondern sich mit ihren Ressourcen an größere Partner „hängen“ und diese dann langfristig mit Ihren Mitarbeitern unterstützen.
Ich habe bei einigen großen Unternehmen externe Mitarbeiter gesehen, die über viele Jahre in Projekten und Abteilungen beschäftigt sind.
Das Besetzen von größeren IT-Projekten – insbesondere wenn die Vorstände die Budgets sehr kurzfristig freigeben um eine Marktchance wahrzunehmen – mit bis zu 80% Externen und davon vielen key-Ressourcen ist bis heute keine Seltenheit.
Woher sonst sollen auch große IT-Dienstleister Spezial-Knowhow beziehen, dass sich ja schon lange nicht mehr auf die Frage Java oder .Net beschränken lässt, sondern diverse Technologien, Frameworks, Tools und Systeme umfasst.
Schließlich ermöglicht eben diese Vielfalt erst schnelles Implementieren, sofern man die richtigen Leute zur richtigen Zeit hat. All das ist nun plötzlich nicht mehr so ohne weiteres erlaubt. Und das ist zunächst ein generelles Problem, SCRUM betrifft es allerdings wegen der schwierigen Planbarkeit in besonderem Maße. Und es kommt noch schlimmer:
created by agile natives for agile natives
Die erste all-in-one scaled agile Projektmanagement Suite für SharePoint.
Wie verlässlich ist Ihr Projektplan in Bezug auf Zeit und Budget?
Nach einer Studie von McKinsey und die Saïd Business School der University of Oxford laufen IT- Projekte ca. 30-mal mehr aus dem Ruder, als in anderen Branchen die üblichen 0,7 Prozent. Und darin sind nur die „schwarzen Schwäne“ enthalten, also Projekte, die ihr Budget um mehr als 200 Prozent- und die Zeit um mehr als 70 Prozent übersteigen.
Letzteres interessiert uns hier in Bezug auf die AÜG Problematik. Denn selbst Projekte, die „nur“ eine Laufzeit von 12 Monaten haben sollen, laufen bereits Gefahr, ihre externen Mitarbeiter zu verlieren, wenn sie in diese Rubrik fallen und das Projekt plötzlich und unerwartet doch „etwas“ länger braucht.
Dazu kommt, dass die Statistik sich auf IT-Projekte im Allgemeinen bezieht. SCRUM Projekte, deren Ziele in Bezug auf Zeit ohnehin eher vage sind, haben hier noch einmal etwas größere Risiken.
Ist SCRUM jetzt das Problem oder schon die Lösung?
Das sind zunächst keine gute Aussichten für sehr viele IT-Projekte. Eine Menge Unternehmen haben gerade den (richtigen) Schritt in Richtung SCRUM vollzogen und nun dies. All das, was wir gerade lieb gewonnen haben wird zum Risiko, quasi vom hässlichen Entlein zum schönen Schwan und zurück.
Ich bin nicht der Meinung der Kollegen von der Computerwoche oder diversen Anwaltsratgebern zu diesem Thema, dass dieses Problem ein Vertragliches ist und durch die geschickte Gestaltung von Werkverträgen gelöst werden kann. Denn erstens sind die Möglichkeiten hier faktisch begrenzt und zweitens zielt das Gesetz mit dem Verbot von Scheinwerkverträgen ja gerade darauf, solche listigen Tricks zu unterbinden.
