Ganz sicher gibt es glühendere Anhänger der reinen agilen Lehre als mich. Die Vorgehensweise im Projekt muss passend sein und nicht standardisiert. Was da aber unter dem Schlagwort Scrum oder agiles Vorgehen in der Praxis verstanden und vor allem missverstanden wird, ist vorsichtig ausgedrückt abenteuerlich. Ein Gutteil der schlechten Erfahrungen mit Scrum liegt definitiv in der mutlosen Umsetzung und einer damit einhergehenden Verstümmelung der Methodik bis zur Unbrauchbarkeit.
Mache die Dinge so einfach wie möglich – aber nicht einfacher.
Albert Einstein
Zu Projektbeginn werden gerne nur die Vorteile der agilen Vorgehensweise gesehen und im Angebot angepriesen: Schnell den Kurs ändern zu können, in kurzen Abständen Ergebnisse sehen, eng verzahnt interdisziplinär im Team arbeiten, nicht nur betroffen zu sein, sondern beteiligt. Die anfängliche Euphorie verfliegt dann schnell, wenn das Projekt mit der harten Realität und der Formalität der umgebenden Organisation konfrontiert wird.
Das beginnt bei der vertraglichen Situation, die meist ein Festpreis für einen anfangs definierten Umfang ist, beispielsweise in Form eines fertigen Fachkonzepts, das umgesetzt werden soll. Auf Arbeitsebene kann man sich nun darauf einigen, diesen Festpreis als Kontingent zu betrachten und entsprechend eines Backlogs umzusetzen bis das Kontingent ausgeschöpft ist. Bei einigermaßen akribischer Buchführung lässt sich das auch sauber auf die ursprüngliche Beauftragung abbilden. Andererseits ist die Kundenseite oft eher klassisch im Sinne einer langfristigen Budgetplanung unterwegs. Dort hat der verantwortliche Projektleiter dann einen Projektauftrag in dem er beispielsweise die Umsetzung eben dieses Fachkonzepts verspricht und woran er gemessen wird. Das wird so aber nicht passieren und soll so auch nicht passieren, wenn man agil vorgeht. Also ist auch der Kunde akribisch damit beschäftigt die Dokumentation an die agil geschaffene Realität anzupassen. Klingt nicht nur mühsam, ist es auch. Für alle Seiten.
Die nächste Hürde sind dann formale Anforderungen, die noch aus Zeiten des Wasserfallmodells stammen. Natürlich braucht man eine tragfähige Architektur. Das heißt aber nicht, dass man zu Beginn alle Eventualitäten und Anforderungen, die im Laufe der nächsten Jahre auftreten könnten, in voller Schönheit analysieren muss. Natürlich haben diesen Fragen ihre Berechtigung, aber der Gedanke der möglichen und sogar nötigen Absicherung im Vorfeld ist fehl am Platze. Diese Fragen werden dann beantwortet, wenn sie sich wirklich stellen. Und die Antwort kann auch ein Refactoring, also einen großflächigen Umbau der Anwendung, bedeuten. Das klingt zunächst nach mehr Aufwand, ist es aber nicht, wenn man sich die überflüssigen Trockenübungen zu Beginn in Form eines detaillierten IT-Konzepts spart.
Bleibt noch die Projektplanung. Recht einfach eigentlich im agilen Vorgehen. Im wesentlichen besteht die Planung aus einer Menge von Sprints plus ein paar formale Meilensteine wie der gemeinsame Integrationstest in einer Systemlandschaft. In eher klassisch geprägten Organisationen befriedigt diese Planung das Kontrollbedürfnis aber nur unzureichend. Schnell kommt der Wunsch auf, die Sprints detailliert mit Inhalt auszuplanen, damit man genau weiß, wann welche Funktionen umgesetzt werden sollen. Sonst weiß man doch gar nicht was genau man am Ende bekommt. Ja, genau das ist die Idee! Weil man nämlich vorher gar nicht genau genug spezifizieren kann, was man braucht.
Fazit
Das agile Vorgehen im realen Leben, gerade in eher klassischen Organisationen, ist mit vielen Herausforderungen konfrontiert und oft nur ein bisschen agil oder eben ScrumBut. Von vielen Seiten wird die reine Lehre verwässert und teilweise bis zur Unkenntlichkeit verstümmelt. Manche Anpassungen oder Rahmenbedingungen können einigermaßen passend gemacht werden, beispielsweise die Festpreise oder die Forderung nach einem mehr oder weniger detaillierten IT-Konzept, andere sind hochgradig schädlich, beispielsweise die detaillierte Planung.
Artikelbild: Trevor Leyenhorst bei flickr.com (CC BY 2.0)
Jetzt erhältlich
Das Manifest für menschliche Führung wird erwachsen. Komplett überarbeitet und deutlich erweitert sind die 6 Thesen und 14 Prinzipien für eine neue Führung im Zeitalter der Digitalisierung ab 14. Februar 2024 als Hardcover in hochwertiger Leinenbindung erhältlich.
8 Kommentare
„Die Vorgehensweise im Projekt muss passend sein und nicht standardisiert.“
JA!!!
„Ein Gutteil der schlechten Erfahrungen mit Serum liegt definitiv in der mutlosen Umsetzung und damit einhergehenden Verstümmelung der Methodik bis zur Unbrauchbarkeit.“
NEIN. Genau HIER liegt der Denklfehler, der als „agiles Mantra“ immer wieder behauptet wird: Der Fehler liegt in der unreflektierten Grundannahme, dass Scrum „out of the book“ am besten funktioniert und alle Abweichungen dafür zu Misserfolgen führen.
Wenn eine an Scrum angelehnte, dieses aber weitgehend verändernde, Vorgehensweise, nicht funktioniert, dann liegt in der Regel nicht an dieser Vorgehensweise sondern sehr oft daran, dass es an professioneller Arbeit (Craftmanship) etwa im sinn des Clean Code Development fehlt, und an einer schlampigen bis fehlenden Architektur und an einem „RE auf Zuruf“ liegt.
„Dort hat der verantwortliche Projektleiter dann einen Projektauftrag in dem er beispielsweise die Umsetzung eben dieses Fachkonzepts verspricht und woran er gemessen wird- Das wird so aber nicht passieren und soll so auch nicht passieren, wenn man agil vorgeht. Also ist auch der Kunde akribisch damit beschäftigt die Dokumentation an die agil geschaffene Realität anzupassen. Klingt nicht nur mühsam, ist es auch- Für alle Seiten.“
GENAU: „Das wird so aber nicht passieren und soll so auch nicht passieren, wenn man agil vorgeht.“ Damit ist klar: Die Probeleme entstehen durch das agile Vorgehen. Meine Erfahrung ist, dass statt ein Clean Code Development, eine tragfähige Architektur und ein professionelles RE anzustreben der einfache weg gegegangen wird: All das wird kurzerhand als „zu komplex“ erklärt und inspiriert vom Agilen Manifest das intuitive Improvisieren zur offiziellen Methode als „Scrum“ glorifiziert. Das ist nämlich viel einfacher.
„Die nächste Hürde sind dann formale Anforderungen, die noch aus Zeiten des Wasserfallmodells stammen“
WIE BITTE??? „Formale Anforderungen“ als „böser Wasserfall“??? Also: Besteht die „agile“ Lösung darin, Anforderungen umfassender Systeme nur auf Basis von Stichworten („Als … will ich … damit …“) zu beschreiben, die dann erst „on fly“ (also beim Programmieren) mit dem danebensitzenden Benutzer präzisiert werden? Da waren wir ja bei XP mit dem CRC schon präziser…
„Natürlich haben diesen Fragen ihre Berechtigung, aber der Gedanke der möglichen und sogar nötigen Absicherung im Vorfeld ist fehl am Platze. Diese Fragen werden dann beantwortet, wenn sie sich wirklich stellen.“
WIE BITTE??
Für das Realisisieren von Webshops für Weihnachtskerzen mag das ja genügen, nicht aber für Systeme mit hohen Risikopotential, die VORHGERIGER behördlicher Prüfungen bedürfen.
Ken Schwabers Scrum-Beschreibung von 1995 (agilix.nl/resources/scrum OOPSLA 95.pdf) ist da viel realistischer, siehe dort 4.1 und in 4.2.1 „Assessment of risk and appropriate risk controls“ und in 4.2.2 „Perform domain analysis to the extent required to build, enhance, or update the
domain models to reflect the new system context and requirements / Refine the system architecture to support the new context and requirements“
Erst auf DIESER Basis kann innerhalb der Sprints das sinnvoll geleistet werden: „Risk is assessed continuously and adequate risk controls and responses put in place.“
„Das klingt zunächst nach mehr Aufwand, ist es aber nicht, wenn man sich die überflüssigen Trockenübungen zu Beginn in Form eines detaillierten IT-Konzepts spart.“
Ein detailliertes IT-Konzept habe ich in meinen rund 30 Jahren in der IT noch nie erlebt. Alle waren nur so weit ausformuliert als es möglich und nötig war. Die Details ergaben sich auch früher immer schon im Rahmen der Realisierung. Leider wurde deren Rückwirkungen auf das Konzept i.a. nicht dokumentiert – sodass die anschliessende Wartung keine tragfähige Informationen mehr hatte. Das ist aber kein Grund, nun auf solche Konzepte zu verzichten! Dieser Verzicht nämlich führt zur schlechteren Wartbarkeit und Erweiterbarkeit agil erstellter SW, siehe vorletzte Zeile in der Tabelle auf Seite 120 in http://www.korn.ch/archiv/publikationen/Neuer-Wein-in-alte-Schlaeuche-oder-Deja-vu.pdf
„Schnell kommt der Wunsch auf, die Sprints detailliert mit Inhalt auszuplanen, damit man genau weiß, wann welche Funktionen umgesetzt werden sollen.“
Bei kleinen Vorhaben mit Durchlaufzeiten von bis zu 6 Monaten ist der wunsch nachvollziehbar und auch vernüftig – und zwar im sinn einer PLANUNG, nicht im Sinn einer Garantie (die nach meiner Erfahrung auch kaum jemand fordert).
Bei grossen Vorhaben wird dan auf meiner Erfahrung nie gefordert – weil jeder weiss, dass das nicht funktioniert. Erwartet aber wird – zu Recht etwas im Sinn der Punkte 1 bis 5 in http://scaledagileframework.com/roadmap/
„Sonst weiß man doch gar nicht was genau man am Ende bekommt. Ja, genau das ist die Idee! Weil man nämlich vorher gar nicht genau genug spezifizieren kann, was man braucht.“
WIE BITTE? DIE IT DARF DAS LIEFERN WAS SIE WILL / KANN?
Wenn ein IT-Supplier nicht in der Lage ist, im Sinn der oe.e Punkte 1 bis 5 Aussagen zum Endergebnis zu machen, dann ist er schlichtweg inkompetent.
Der zunehmend schlechte Ruf von „agil“ beruht auf genau sochen als Ausreden gesehenen Aussagen: „man kann vorher gar nicht genau genug spezifizieren was man braucht“.
Kein Bauherr würde einen Bauunternehmer beauftragen, der so etwas sagt.… und schlussendlich für 1 Mio € eine Schrebergartenhütte erhält …
Danke für diesen ausführlichen Kommentar, wenngleich ich ihn mir in einem etwas wertschätzenderen Ton gewünscht hätte.
Ohne nun auf die einzelnen Punkte einzugehen, was den Rahmen hier sprengen würde, ein paar Anmerkungen zum Verständnis. Ich bin der letzte der sich für eine dogmatische und schematische Anwendung von Scrum nach Lehrbuch stark macht. Darum ging es mir nicht. Wir sind uns einig, dass das Vorgehen zum Projekt passend zugeschnitten werden muss.
Dabei kann man es aber auch übertreiben und Scrum unzulässig verstümmeln. Insbesondere dort wo die umgebende Organisation noch sehr klassisch tickt. Das meinte ich mit formalen Anforderungen, also Artefakte, die formal gefordert sind oder zur Absicherung der beteiligten Parteien notwendig erscheinen. Das soll nun nicht heißen, dass kritische Teile (z.B. die genannten behördlichen Anforderungen) nicht frühzeitig abgesichert werden sollten, aber eben nicht alles und nur um der Form willen. Anforderungsmanagement ist ein ganz anderes Thema, das im Scrum meiner Meinung nach sogar recht stringent und konsequent erfolgt.
Ich wollte nicht sagen, dass die IT liefern kann und darf, was sie will. Aber ich habe oft genug gesehen, dass sich viele wichtige Anforderungen erst auf dem Weg ergeben und man tatsächlich nicht vorher nicht vollständig sagen kann, was man am Ende brauchen wird. Am Bau ist das übrigens auch so: im Detail ergibt sich vieles erst auf dem Weg.
Eine „unzulässige Verstümmelung von Scrum“ gibt es nicht.
Jegliche Veränderung von Scrum führt – gemäss dem Wunsch von Ken und Jeff – zu etwas, das nicht „Scrum“ genannt werden darf.
Und ein – nicht Scrum genanntes – Vorgehen mit nur einigen Elementen von Scrum ist nur dann kontraproduktiv, wenn die Entwicklungsergebnisse ungenügend sind. Das liegt aber i.a. nicht m Vorgehen als solchem sondern an vielen der „Craftmanship“ widersprechenden Praktiken.
Ja – Detailanforderungen ergaben sich immer schon „on fly“. Auch in Bauprojekten etwa von EFHs. Und diese werden nach wie vor „klassisch“ abgewickelt. Und dennoch funktioniert das. Dass sie „in time & budget“ realisiert werden ist die dabei auch die Regel, nicht die Ausnahme. Weil es eben eher kleine Projekte sind. Und die sind – auch in der IT – gemäss CHAOS-Report signifikant erfolgreicher als grosse.
Bei Bauprojekten ist der Anspruch an „Craftmanshhoip“ zusätzlich auch sehr ausgeprägt.
Genau dort sehe ich das Kernproblem der IT.
Und im Drang nach Grossprojekten.
Herr Korn lässt seinen Frust mal wieder in anderer Leuten Blogs heraus; wird das eigene nicht genügend beachtet? Und wer sich auf den intransparenten CHAOS-Report beruft, kann auch gleich BILD zitieren…
Wenn ein Blog die Möglichkeit zur Diskussion bietet, dann ist deren Nutzung wohl kein „Ablassen von Frust“…
Und, ja: Der CHAOS-Report ist recht umstritten … wird aber dennoch gerne als Beweis des Nutzens agiler Projekte gedeutet.
Agile Strukturen spiegeln vor allem eine Partnerschaft zwischen Auftraggeber und Auftragnehmer zum gemeinsamen Projekterfolg wider. Der Auftraggeber übernimmt als Product owner Verantwortung für die fachliche Ausgestaltung der gewünschten Funktionen, der Auftragnehmer ermöglicht das durch passende, pragmatische Strukturen und schnelles, verständliches Feedback.
Hier liegt IMO auch das Problem, denn in manchen (gerade großen) Projekten ist von Partnerschaft nicht viel zu spüren. Wer als Auftraggeber ängstlich bemüht ist, möglichst alle eigene Verantwortung über Pflichtenhefte, fremde Kalkulationen und Verträge wegzudelegieren, der kann nicht plötzlich „agil“ arbeiten. Wenn ein Klima von Rechtfertigungsdruck und Missgunst den Auftraggeber beeinflusst, dann wird sich das in Projektstrukturen niederschlagen, die zulassen, jederzeit mit dem Finger auf andere zu zeigen. Feste Budgets, definierte Beauftragungen und unverrückbare Zeitpläne helfen da, davon profitieren klassische Managementmethoden.
Es wird etwas leichter, wenn sich Auftraggeber und ‑nehmer in der gleichen Organisation befinden. „Agil“ funktioniert somit bei internen Produktentwicklungen besser, weil die Methode hier leichter anzuwenden ist.
JA!
Diese heute unter „agil“ subsumierten Prinzipien sind in der Organisationsentwicklung schon jahrzentelang bekannte und diskutierte Ideen. Einige davon wurden – allerdings in vergleichsweise wenigen Fällen – erfolgreich umgesetzt.
In nur wenigen Fällen deshalb, weil der Versuch, diese Prinzipien im Rahmen der mehr-heitlich etablierten Führungsstrukturen und Projektkontexten (AG – AN – Beziehung) ein im grundsätzlich verändertes Denken und Handeln erfordert. Dieses veränderte Denken und Handeln setzt voraus, dass beginnend bei der Unternehmensspitze
o das „alles im Griff haben“ ersetzt ist durch ein „vertrauensvolles Loslassen“. Also: „Kontrolle ist gut – Vertrauen ist besser“
o die Überzeugung vorherrscht, dass ein Unternehmen erst durch die fortlaufende Konversation aller das Unternehmen umfassenden Mitarbeitenden und Stakeholder entsteht, nicht durch von oben verkündete Visionen oder verordnete Strukturen.
Diese Voraussetzungen zu erfüllen ist jedoch sehr anspruchsvoll.
Danke für den Kommentar, der sich mit meiner Erfahrung deckt. Letztlich ist es immer eine Frage der Partnerschaft zwischen Auftraggeber und Auftragnehmer. Wenn in dieser Partnerschaft zu wenig Vertrauen vorhanden ist, wird es ganz ganz schwierig mit dem gemeinsamen agilen Vorgehen.