Die kurze Antwort ist: Unter Umständen ja. Das Nachdenken über die Umstände hat mich dazu gebracht, den nachfolgenden Blog-Post zu schreiben.
Wenn Unternehmen ihr Projekt- und Produktentwicklungsvorgehen von klassischen, wasserfallartigen Modellen auf agile Methoden umzustellen, handelt es sich dann sehr oft um Scrum oder daran angelehnte Methoden. Wenn ich in solch einem Fall mit meinen Kunden spreche, und frage, warum man denn Scrum einführen möchte, bekomme ich sehr oft die Antwort: „Wir wollen schneller werden“.
Daran ist zunächst einmal nichts falsches. In gängiger Literatur liest man auch immer wieder so etwas wie „… nach der Umstellung auf Scrum konnte das Projekt um X Wochen früher abgeschlossen werden“, oder „… durch Scrum liefern wir unsere Releases jetzt schneller“. Nur zu verständlich ist es dann, dass Entscheider in Unternehmen auf die Anforderung „ihr müsst schneller werden“ die Antwort in Scrum sehen.
Wenn ich mit meinen Kunden diese Frage bespreche, wünsche ich mir oft ein kritischeres Nachfragen, warum denn Scrum eigentlich schneller macht. Denn eines sollte doch zum denken anregen: Nur weil man die Vorgehensweise ändert, werden die Menschen in einem Unternehmen nicht plötzlich die gleiche Menge Arbeit in kürzerer Zeit erledigen. Oder doch?
Zudem bringt Scrum einen nicht unerheblichen Kommunikations- und Abstimmungsbedarf mit sich, gerade bei ungeübten Teams. So ist es nicht unüblich, dass Teams bei der Einführung von Scrum zunächst einmal langsamer in der Umsetzung werden. Wird man denn nun schneller und wenn ja, wie?
Im Wesentlichen sorgen zwei Aspekte in Scrum dafür, dass Teams Ihre Arbeit schneller erledigen können:
- Cross-Funktionale Teams, und
- Fokus auf das Minimum Viable Product oder die Menge an nicht-getaner Arbeit zu maximieren.
Daher ist es extrem wichtig, diese Aspekte bei der Einführung auch konsequent umzusetzen um den vollen Nutzen der agilen Vorgehensweise zu erreichen. Wenn Sie hier zum so genannten “Scrum, but” – also, wir machen Scrum, aber … (lassen ein paar Dinge weg) – verfallen, werden Sie früher oder später auch dem Trugschluss erliegen, dass “Scrum ja nicht funktioniert”.
Cross-Funktionale Teams
Kurz gesagt sorgen Sie mit cross-funktionalen Teams dafür, dass im Team alle Fähigkeiten existent sind, die es zur Erfüllung seiner Aufgaben braucht. Wenn Teams sich “nach außen” wenden müssen um bestimmte Dinge erledigen zu können, wird sie das unweigerlich bremsen.
Nehmen Sie zum Beispiel ein Team an Programmierern, dass eine Web-Anwendung erstellen soll. Damit die Nutzer darauf zugreifen können, muss ein Netzwerkadministrator diverse Änderungen an der Firewall machen. Der Administrator arbeitet in der Abteilung der Netzwerk-Security in einem völlig anderen Gebäude. Um die Änderungen an der Firewall zu bekommen, muss das Team ein Ticket erstellen und dann auf dessen Umsetzung – oft viele Wochen – warten.
Ein solches Szenario ist leider noch Alltag in vielen Unternehmen. Stellen Sie sich nun vor, sie nehmen die Sache mit den cross-funktionalen Teams ernst. Dann würden sie den Kollegen aus der Abteilung der Netzwerk-Security direkt in das Team der Programmierer packen. Oder alternativ einen Kollegen im Team befähigen, Firewall-Änderungen selbst zu durchzuführen. Die Kollegen sitzen plötzlich nebeneinander. Um eine Änderung an der Firewall zu machen braucht es dann vielleicht nur noch ein 5-Minütiges Gespräch und ein paar Anpassungen in einer Konfigurationsdatei, die in weiteren 10 Minuten gemacht, geprüft, dokumentiert und getestet werden kann. Fertig.
Ich gebe zu, diese Schilderung ist stark vereinfacht aber ich hoffe, das Prinzip wird klar. Lesen Sie doch zu dem Thema auch meinen Blog-Artikel “Jeder kann alles – Missverständnis Cross-Funktionales Team”, in dem ich detaillierter darauf eingehe.
Das Minimum Viable Product
Eine wichtige Lehre aus Jahrzehnten der Durchführung von IT-Projekten nach dem „Plan-Build-Run“ Prinzip mit ausgedehnten Konzeptions- und Spezifikationsphasen ist, dass dies häufig zu aufgeblähten Lösungen führt. Also Lösungen, mit vielen Features, die nur wenig oder überhaupt nicht genutzt werden. Der Hauptnutzen der Lösung wird durch wenige Kernfeatures dargestellt. Etliche Studien dazu besagen, dass bisweilen mit nur ca. 20% der Produktfeatures bis zu 80% des Produktwertes realisiert wird – das Pareto-Prinzip lässt grüßen.
Aus diesen Erkenntnissen ist in Scrum ein wichtiges Prinzip entstanden: Die Maximierung der nicht getanen Arbeit, in dem man immer wieder nach der einfachsten, schlankesten Lösung für ein Kundenbedürfnis sucht. Die Konzentration auf die eigentlichen Kundenbedürfnisse ist das meines Erachtens am meisten unterschätzte Werkzeug in der agilen Vorgehensweise.
Genau genommen braucht man dazu nicht einmal einen agilen Rahmen, aber es bedarf doch einiger Übung und den berühmten „Shift in Mindset“, um sich immer wieder auf das so genannte „Minimum Viable Product“ (MVP) zu konzentrieren. Dahinter stecken kontinuierlicher Kundenkontakt, Fokus auf Probleme anstatt technischer Lösungen beim Requirement-Engineering, und das permanente Hinterfragen eines Lösungsweges. Sich die Freiheit zu nehmen, Dinge nicht zu tun, wird hier ein entscheidender Vorteil.
Probleme statt Lösungen
Aber wie erlangt man die Freiheit, „Dinge nicht zu tun“? Übung, Kreativität und auch eine Portion Dogmatismus, den Scrum-Prinzipien zu folgen, sind hier aus meiner Sicht sehr hilfreich. Kreativität fördern Sie auch hier wieder durch cross-funktionale Teams, in denen Fähigkeiten aus verschiedenen Disziplinen vertreten sind.
Ein weiterer entscheidender Schlüssel liegt meines Erachtens darin, dass die umzusetzenden Features vom zu lösenden Problem her gedacht und formuliert sein sollten. In der Praxis sehe ich oft (sehr technische) Lösungsansätze, die in User-Storys verpackt sind. Das passiert besonders dann, wenn z.B. Product Owner und Stakeholder aus einem sehr technischen Umfeld stammen. Es ist dann um so wichtiger, durch Coaching und ständiges “üben”, zu gut formulierten Anforderungen zu kommen, die das zu lösende Kundenproblem aus Nutzersicht beschreiben. User-Storys wie sie im Extreme Programming gängig sind, können hier sehr hilfreich sein. Aber auch Verfahren wie Impact Mapping oder Value Proposition Design sind gute, problemorientierte Ansätze.
Jetzt werden viele unter Ihnen sagen: „Ja, aber so einfach ist das bei uns nicht, wir bauen hier eine ganz komplizierte Sache und die Kunden verstehen das nicht“. Nun, Sie haben Recht!“ Ziehen Sie die richtige Konsequenz daraus und sprechen Sie mit Ihrem Kunden über seine Probleme. Kapseln Sie die Komplexität der technischen Lösung von ihm ab.
Geben Sie sich und ihren Teams Zeit zu lernen. Lassen Sie auch Software bauen, von der Sie bereit sind, sie am nächsten Tag wieder wegzuwerfen und neu zu bauen, weil sie dazugelernt haben. Entwickeln Sie Lösungen für akute Probleme und vermeiden Sie, Lösungen für Probleme zu erarbeiten, die Sie zukünftig vielleicht einmal haben werden. Das Prinzip gilt übrigens nicht nur für Software.
Vermeiden sie den Anspruch, es bei der ersten Lösung gleich richtig zu machen, sonst vermeiden Sie auch das Lernen in ihren Teams. Sorgen sie dafür, dass Ihre Teams die eigentlichen Probleme kennen und verstehen, die es zu lösen gilt. Besetzen Sie Ihre Product Owner mit Bedacht. Sorgen Sie dafür, dass Ihre Teams den Input der wirklichen Nutzer bekommen, ohne Filter, ohne stille Post.
Weniger ist mehr
Sorgen Sie also dafür, dass Sie die Menge der Arbeit reduzieren, die Ihre Teams zu bewältigen haben, indem Sie ihnen die Freiheit lassen, eigene, schlanke Lösungen zu entwickeln. Ein gutes Fundament dazu legen Sie, indem Ihre Stakeholder, Kunden und Product Owner über Probleme reden, nicht über Lösungen. Geben Sie ihren Teams den Freiraum, die beste technische Lösung für die Probleme ihrer Kunden zu finden, auch wenn es dazu mehrere Iterationen braucht. Daher meine lange Antwort auf die Eingangsfrage: Unter der Bedingung, dass Sie die Menge an nicht-getaner Arbeit maximieren und echte, cross-funktionale Teams einsetzen, wird Scrum Sie schneller machen!
Wenn Sie hierüber mit mir sprechen möchten oder sich Unterstützung für Ihr Unternehmen wünschen, freue ich mich sehr wenn Sie mich ansprechen.
Herzlichen Dank.
Schreibe einen Kommentar